Можно ли предотвратить пакетное обновление на уровне базы данных sql? - PullRequest
1 голос
/ 23 декабря 2008

Простой тупой "UPDATE table SET something=another WHERE (always true)" при аварии легко уничтожит все в базе данных. Это может быть человеческая ошибка, атака с использованием SQL-инъекции / переполнения / усечения или ошибка в коде, которая создает WHERE.

Предоставляют ли популярные базы данных функцию, которая защищает таблицы путем ограничения максимального количества строк, которые могут быть обновлены в одном операторе SQL?

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

Ответы [ 7 ]

6 голосов
/ 23 декабря 2008

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

1 голос
/ 23 декабря 2008

Как Дэвид Б. первым указал, вы можете сделать это с помощью триггера. В любом случае, полезно начинать свои триггеры с теста @@ ROWCOUNT. Итак, представьте:

CREATE TRIGGER dbo.trg_myTrigger_UD ON dbo.myTable FOR UPDATE, DELETE
AS
IF @@ROWCOUNT <> 1 RETURN

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

Как правило, я начинаю свой тест с счетчика строк <> 0. Дело в том, что если триггер был запущен чем-то, что фактически не затронуло строки (таблица UPDATE SET col1 = 'hey' WHERE 1 = 0) тогда нет смысла проходить через код триггера, так как он все равно ничего не сделает.

1 голос
/ 23 декабря 2008

Краткий ответ "нет" ...

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

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

Большинство ваших сценариев должны рассматриваться другими способами:

  • человеческая ошибка: большинству пользователей не следует предоставлять привилегии на обновление таблиц, они должны быть вынуждены вызывать API (обычно через приложение) для выполнения обновлений. Администраторы баз данных должны быть очень осторожны при доступе к действующим базам данных - не обращайте внимания на ограничения строк, они могут полностью удалить таблицу !
  • Атака инъекцией: их можно и нужно предотвратить
  • Ошибки кода: они должны быть обнаружены при надлежащем тестировании

Если ваши данные важны, они должны быть надлежащим образом защищены и обслуживаться, как указано выше, а максимальный предел обновления строки не требуется; если ваши данные недостаточно важны для защиты, как указано выше, то зачем беспокоиться?

1 голос
/ 23 декабря 2008

Я ничего не знаю.

Я не уверен, что это решит что-нибудь. Как база данных может отличить атаку SQL-инъекцией от ночного пакетного обновления, которое превышает ваш лимит?

Одно предположение, что автоматическая фиксация установлена ​​в true. Если атака с использованием SQL-инъекции не совершена, у вас всегда есть возможность откатить ее, если вы просматриваете журналы и тому подобное.

Я думаю, что реальный ответ - это лучшее наложение приложений, валидация, привязка и т. Д. Вы не можете выполнить SQL-инъекцию, если эти меры внедрены.

0 голосов
/ 23 декабря 2008

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

0 голосов
/ 23 декабря 2008

Я понимаю ваши причины, но как вы хотите обрабатывать партии, которые являются законными?

Если вы вносите какие-то изменения вручную и хотите, чтобы изменения были отменены, используйте транзакции. Если вы хотите иметь возможность восстановить данные, используйте архив изменений. Но вы не можете создать проверку для «это правильная / неправильная партия» только из партии со 100% правильными результатами.

0 голосов
/ 23 декабря 2008

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

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