Интегрированная безопасность SQL Server

Question

Я долго искал, чтобы разобраться с проблемами безопасности в SQL Server. Мы разрабатываем приложение.NET для SQL Server 2008 и хотим использовать FileStream.

Теперь я обнаружил, что SQL Server разрешает FileStream только через Win32 API, если вы используете Integrated Security. Проблема в том, что у нас около 80% нашего приложения завершено, но оно полностью основано на аутентификации SQL. Таким образом, мы выполняем INSERT прямо из нашего приложения и не используем хранимые процедуры для каждой операции CRUD.

Это относительно безопасно, потому что я могу хранить имя пользователя и пароль SQL в зашифрованном виде. Я знаю, что пароль передается в открытом тексте, но я готов принять это.

Мы хотим, чтобы конечные пользователи могли подключаться к базе данных с помощью таких инструментов, как Crystal Reports, и для этого у нас есть дополнительная учетная запись SQL, которая имеет только предоставленные права SELECT.

Теперь, если мы перейдем на Integrated Security, нам нужно будет предоставить отдельным пользователям (через группы AD и т. Д.) Права на то, что может делать приложение. В противном случае приложение не сможет выполнить свою работу. Но тогда конечный пользователь также будет иметь эти права, когда он подключается напрямую к БД.

Я вижу людей, которые говорят, что вы должны использовать хранимые процедуры для каждой операции CRUD и предоставлять права EXEC только группе AD, но как мне это сделать? Я не вижу, как у пользователя были бы разные полномочия, когда он подключался напрямую или через приложение... Может кто-нибудь просветить меня об этом.

Дополнительный вопрос о бонусных баллах: насколько я понимаю, Intergrated Security не будет работать в рабочей группе. Как люди заставляют FileStream работать в рабочей группе? Или это считается невозможным?

Answer 1

1. Интегрированная безопасность БУДЕТ работать в рабочей группе, используя устаревший механизм, где у вас есть совпадающее имя пользователя и пароль на двух машинах. Кроме того, пользователь домена может использовать устаревший механизм для входа на сервер вне домена, если на сервере имеется соответствующая учетная запись пользователя.

2. Интегрированная безопасность может даже работать с несоответствующими именами пользователей и паролями. Это может помочь вам в вашем сценарии.

Попробуй это:

NET USE \\DBSERVER /USER:DOMAIN\USERNAME 

Вам будет предложено ввести пароль. Это устанавливает сеанс NetBIOS с сервером базы данных. После этого вы сможете увидеть общие папки и общие принтеры на сервере базы данных.

После установления сеанса netbios между клиентским компьютером и сервером базы данных вы ТОГДА сможете использовать встроенную защиту без запроса пароля.

Возможно, вам придется указать "именованные каналы" в качестве сетевого протокола для использования, если он не работает с TCP (но я думаю, что это будет). Именованные каналы наследуют ваш существующий сеанс NetBIOS, поэтому при условии, что вы можете перечислить общие ресурсы, которые вам, вероятно, пригодятся.

Вы также можете установить сеанс входа в систему с помощью функции Windows API NetUseAdd с USE_INFO_2 (уровень 2) информация, которая включает в себя пароль.

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