Мы только что приобрели программу, которая требует, чтобы у пользователей была учетная запись на сервере MS SQL с доступом для чтения / записи к базе данных программы.
Меня беспокоит то, что, поскольку эти пользователи теперь будут иметь доступ для записи в базу данных, они могут напрямую подключаться к серверу SQL за пределами клиента программы, а затем возиться с данными непосредственно в таблицах.
Могу ли я предотвратить доступ к базе данных, но при этом разрешить доступ через клиентскую программу?
Изменить: SQL 2008 Express, при необходимости можно обновить до SQL 2008 R2 Standard.
Каждой рабочей станции потребуется доступ, чтобы люди могли регистрировать свои часы / расписание. Рабочие станции заблокированы, поэтому ни у кого нет osql, менеджера студии или чего-то подобного. Однако они могут настроить источник данных ODBC, а затем подключиться через Excel / Access.
Просто подумайте об этом сейчас, возня с данными больше не является большой проблемой, есть проблемы с конфиденциальностью, поскольку в этой системе будут ставки оплаты и т. Д.
Согласен, это очень плохой дизайн.
Я немного опоздал с этим, и я согласен с тем, что вы должны указать виноватому в разработчиках приложения, и я бы изложил свои опасения в письменной форме и попросил кого-нибудь, обладающего политической властью, понять риски, но я надеюсь дать вам еще параметры.
Если бы я действительно застрял, я бы подумал о создании триггера для события LOGON. В триггере я бы нашел способ различать то, что я называю «законным» входом в систему и «незаконным» входом в систему, и останавливать незаконный вход в систему от завершения. Законный вход в систему - это подключение пользователей к соответствующей базе данных с помощью соответствующего приложения, а также любые административные входы, входы в систему и т. Д., Которые могут вам понадобиться. Я был бы очень осторожен при написании этого, так как это кажется хорошим способом заблокировать себя от сервера. BOL говорит, что LOGON TRIGGERS доступны в SQL 2008, я почти уверен, что они доступны в Express.
Проблема с этой тактикой заключается в том, что вы можете оказаться в игре «бить молота», когда вы исключаете Excel и Access, затем кто-то выясняет, как написать быстрое приложение vb.net, которое позволяет им войти, а затем вы блокируете это , затем кто-то изменяет строку подключения, чтобы изменить имя приложения и т. д. Чем более осведомлены ваши пользователи, тем труднее будет их остановить. Если у вас есть разработчики, они могут посчитать это проблемой. Я бы сказал, что любой, кто агрессивно пытается найти способ обойти меры безопасности, даже если эти меры не идеальны), является проблемой. (Если я заблокирую дверь с сеткой в своем доме, становится совершенно очевидно, что я не хочу, чтобы кто-то входил. Если кто-то использует карманный нож, чтобы разрезать экран и войти, он определенно сделал что-то неправильно.)
Еще нужно выполнить запрос к DMV, чтобы найти пользователей, которые не играют по правилам. Вы можете получить информацию об имени пользователя, хоста и приложения из системного DMV. Если вы запускаете запрос периодически (раз в минуту или около того) и сохраняете результаты в таблице, вы можете смотреть каждый день (или неделю), а затем бить плохих актеров по костяшкам пальцев. Или пусть это сделает HR.
Еще одна вещь, которую стоит попробовать: если у вас есть что-то, что ищет и сообщает о длительных запросах, вы можете искать «странные» запросы. Однажды я заметил, что кто-то что-то делает, просматривая журналы на предмет проблемных запросов. Часто неопытные пользователи, которые ковыряются, будут запускать неэффективные запросы, которые либо читают много данных, либо вызывают длительные блоки. Иногда, если приложение имеет определенный, определенный «стиль» в способе написания запросов, вы можете выбрать запросы, написанные кем-то (или чем-то) еще. IOW, если использовать очень надуманный пример, есть большая разница между:
выберите * из зарплаты, где сотрудник = "я"
и
выберите * из зарплаты по salary_amount
Подводя итог: лучше всего исправить приложение. Запрет входа в систему может быть нормальным. Все, что вы можете сделать - это попытаться найти нарушителей постфактум.
Нет. Если у пользователей есть доступ для чтения / записи к базе данных и они могут подключаться к ней, не используя программу, они могут сделать что-то вроде UPDATE sometable SET attribute = NULL; и уничтожьте свой набор данных или внесите произвольные изменения, которые захотят.
К сожалению, разрешения SQL не могут выразить концепцию нормальных и вредоносных изменений, сделанных людьми, у которых в противном случае есть доступ, и я подозреваю, что отказать им в разрешении на обновление записей было бы несколько обреченным на провал.
Как и комментарий Джоэла, я бы попросил вернуть деньги, если это вызывает беспокойство в вашей среде. Часто делайте резервные копии и журналы;)
Если у вас есть способ предотвратить вход в систему без использования приложения (например, путем ограничения подключений к одному источнику, если ваше приложение работает через службы терминалов или Citrix), вы определенно можете использовать это для повышения безопасности.