Рекомендации по EntityFramework RE: Защита базы данных

У меня возникла ситуация, когда я хочу использовать разрешения для объектов базы данных, но не позволяю пользователям, которые достаточно умны, чтобы делать подключения через excel и доступ к управлению данными. Мы хотим, чтобы пользователь установил соединение через наше веб-приложение, это гарантирует проверку данных в одном месте. Есть ли способ гарантировать, что когда пользователь устанавливает соединение с базой данных и имеет набор разрешений, который позволяет ему вставлять, обновлять или удалять, что он делает через веб-приложение?Рекомендации по EntityFramework RE: Защита базы данных

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

источник

2012-02-02 bdparrish

Не дать пользователям доступ к базе данных. Имейте единый логин базы данных для веб-сайта. – TGnat

Прочтите последнее предложение. – bdparrish

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

Как только вы предоставляете пользователю доступ к базе данных, он может делать все, что разрешает ему разрешение. Не будет ничего, что не позволит пользователю напрямую обращаться к базе данных. Более того, если вы не используете главную учетную запись в веб-приложении, вам придется делегировать пользователя через веб-приложение (для этого требуется домен Windows и Kerberos, если сервер базы данных не находится на том же компьютере, что и веб-приложение). Эта делегация предоставит вашему пользователю точно такие же разрешения в вашем приложении, как у пользователя, без вашего приложения.

источник

2012-02-02 19:25:14

Я знаю, что это не самый правильный способ работы с DbContext, но из-за MOA между моим клиентом и их клиентами я могу использовать 'context.Database.ExecuteSqlCommand()' для отправки объекта в базу данных, что позволяет использование StoreProcedures для снижения риска того, что пользователь сможет вставлять, обновлять или удалять? – bdparrish

Но какая учетная запись будет использоваться для подключения к базе данных из вашего приложения? Если основной учетной записи приложения вы можете использовать то, что захотите. Если учетная запись пользователя, вы все равно не решите основную проблему. Пользователь должен иметь разрешение на выполнение каждой отдельной хранимой процедуры и выбирать данные (иначе вы не можете использовать запросы LINQ) и сможете это сделать без вашего приложения. Поэтому, чтобы обеспечить все проверки, вы должны переместить всю свою логику и проверку на хранимые процедуры. –

Да, вы правы, разрешения будут предоставляться пользователям напрямую на уровне базы данных. Мое решение состояло в том, что поскольку хранимые процедуры имеют имя и параметры, которые не будут общедоступными, это означает, что более вероятно, что пользователь не сможет выполнять функции «Вставка», «Обновить» или «Удалить», поскольку приложение является интрасети приложение, поэтому все пользователи являются внутренними. Единственным другим вариантом, который я нашел, является выполнение триггера входа в систему, но количество дополнительных транзакций, которые должны иметь место для этого, не влияет на риск. – bdparrish

Не уверен, если это поможет:

http://msdn.microsoft.com/en-us/library/cc716760.aspx

источник

2012-02-02 20:05:11 theDOF

Рекомендации по EntityFramework RE: Защита базы данных

ответ

Смежные вопросы