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

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

NET USE \\DBSERVER /USER:DOMAIN\USERNAME 

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

Как только сеанс netbios был установлен между клиентским компьютером и сервером базы данных, вы будете иметь возможность использовать встроенную защиту без запроса пароля.

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

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

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