Препятствование тому, чтобы пользователи удалили данные SQL
DynDNS.com является одним из более крупных поставщиков и извлекает выгоду из широко распространенной поддержки их протокола обновления в устройствах. Это было вокруг в течение долгого времени и довольно хорошо поддерживается. Я ожидал бы, что аппаратный клиент обновления от Cisco был бы так же хорош, как программное обеспечение updater работа одного из компьютеров будет. Я попробовал бы аппаратные средства updater, чтобы видеть, удовлетворяют ли они Ваши потребности и, в противном случае переключитесь на программное обеспечение updater. У основанных на аппаратных средствах клиентов обновления для других сервисов есть поддержка, которая не так стабильна, таким образом, Ваш пробег может варьироваться, если поставщиком не является DynDNS.com.
Как в стороне, я выполняю DtDNS, меньшего динамического поставщика DNS. Существует ограниченное количество устройств, которые поддерживают мой сервис, и я нашел, что многие из них просто повреждаются. DynDNS.com имел намного лучшую удачу в том, чтобы заставлять поставщиков оборудования поддерживать их сервис с клиентами обновления, это на самом деле работает правильно.
Нет. Если у пользователей есть доступ для чтения / записи к базе данных и они могут подключаться к ней, не используя программу, они могут сделать что-то вроде UPDATE sometable SET attribute = NULL; и уничтожить ваш набор данных или сделать что-нибудь произвольные изменения, которые они хотят.
К сожалению, разрешения SQL не могут выразить концепцию нормальных и вредоносных изменений, сделанных людьми, у которых в противном случае есть доступ, и я подозреваю, что отказ им в разрешении на обновление записей был бы несколько обреченным на провал. .
Как и комментарий Джоэла, я прошу вернуть деньги, если это вызывает беспокойство в вашей среде. Регулярно создавайте резервные копии и журналы;)
Если у вас есть способ предотвратить вход в систему без использования приложения (например, путем ограничения подключений к одному источнику,
Я немного поздно, и я согласен с тем, что вы должны указать виноватым на разработчиков приложения и на меня. Я бы изложил свои опасения в письменной форме и попросил кого-нибудь с политической властью понять риски, но я надеюсь дать вам еще несколько вариантов.
Если бы я действительно застрял, я бы подумал о создании триггера для события LOGON. В триггере я бы нашел способ различать то, что я называю «законным» входом в систему, и «незаконным» входом в систему, и останавливать незаконный вход в систему от завершения. Законный вход - это подключение пользователей к соответствующей базе данных с помощью соответствующего приложения, а также любые административные входы, входы в систему и т. Д., Которые могут вам понадобиться. Я был бы очень осторожен при написании этого, так как это кажется хорошим способом заблокировать себя от сервера. BOL говорит, что LOGON TRIGGERS доступны в SQL 2008, я почти уверен, что они доступны в Express.
Проблема с этой тактикой заключается в том, что вы можете оказаться в игре «бей крота», когда исключаете Excel и Access, затем кто-то придумает, как написать быстрое приложение vb.net, которое позволит им войти, а затем вы блокируете это, затем кто-то модифицирует строку подключения, чтобы изменить имя приложения и т. д. Чем более осведомлены ваши пользователи, тем труднее будет их остановить. Если у вас есть разработчики, они могут посчитать это проблемой. Я бы сказал, что любой, кто агрессивно пытается найти способ обойти меры безопасности, даже если эти меры не идеальны), является проблемой. (Если я заблокирую дверь с сеткой в своем доме, становится совершенно очевидно, что я не хочу, чтобы кто-то входил. Если кто-то использует карманный нож, чтобы разрезать экран и войти, он определенно сделал что-то не так. )
Еще нужно просто запустить запрос к DMV, чтобы найти пользователей, которые не играют по правилам. Вы можете получить информацию об имени пользователя, хоста и приложения из системного DMV. Если вы запускаете запрос периодически (раз в минуту или около того) и сохраняете результаты в таблице, вы можете смотреть каждый день (или неделю), а затем бить плохих актеров по костяшкам пальцев. Или попросите HR сделать это.
Еще одна вещь, которую можно попробовать, - если у вас есть что-то, что ищет и сообщает о длительных запросах, вы можете искать «странные» запросы. Однажды я заметил, что кто-то что-то делает, просматривая журналы на предмет проблемных запросов. Часто неопытные пользователи, которые ковыряются, будут запускать неэффективные запросы, которые либо читают много данных, либо вызывают длительные блоки. Иногда, если у приложения есть определенный, определенный "стиль" по способу написания запросов, вы можете выбрать запросы, написанные кем-то (или чем-то) еще. IOW, используя очень надуманный пример, существует большая разница между:
select * from salary where employee = "me"
и
select * from salary order by salary_amount
Подводя итог: Лучше всего исправить приложение. Запрет входа в систему может быть нормальным. Все, что вы можете сделать - это попытаться найти нарушителей постфактум.