Модели безопасности приложений SQL Server и asp.net / лучшие практики
Для моих веб-приложений asp.net против сервера sql (по крайней мере, тех, которые требуют входа в систему для доступа) я обычно реализую безопасность следующим образом:
Обычно я накручиваю свою собственную регистрацию пользователя, страницы входа пользователя и сохраняю идентификатор пользователя и зашифрованный пароль на сервере sql и проверяю логин по этой таблице - я также предоставляю забытые пароли, `` пришлите мне мой пароль '', подтверждение по электронной почте для активации учетных записей и т. д. все через собственный код.
После того, как пользователь был проверен приложением (и предположим, что все пользователи имеют одинаковые привилегии), я обычно использую логонид утилиты, чтобы разрешить asp.net разговаривать с сервером sql, поэтому, другими словами, мне нужно создать только один вход в систему. id для каждого приложения, и поскольку 100% всего доступа к данным осуществляется через хранимые процедуры, мне нужно только предоставить доступ одному пользователю для выполнения хранимых процедур, и никакой другой работы на сервере sql не требуется. Каждое приложение имеет свою собственную базу данных, и вход в систему для этого приложения может получить доступ только к этой базе данных.
Все это отлично работает для меня, единственный минус этого заключается в том, что было бы неплохо иметь возможность настроить трассировку на сервере sql и видеть идентификатор пользователя и вызываемые процессы, но поскольку все пользователи `` разговаривают '' с база данных через один вход в базу данных, этого не может произойти.
Итак, вопрос из двух частей:
1) Есть ли у вас, ребята, модели безопасности, которые мне следует рассмотреть? Легко всегда делать одно и то же снова и снова - тем более, что это работает - но есть ли другие модели, которые будут работать лучше или которые мне следует рассмотреть? Рекомендуется ли на практике, чтобы весь доступ к базе данных из приложения asp.net использовался для одного входа в базу данных? или это считается плохой практикой? и если да, то почему?
2) Предполагая, что я придерживаюсь своей модели, есть ли способ разрешить отображение идентификатора входа в приложение в окне трассировки sql? Было бы неплохо видеть вызываемый sp и идентификатор пользователя человека, вошедшего в систему (не логин базы данных).
Ответы 6
1) Пока вы используете хранимые процедуры для доступа, одного входа может хватить. Некоторым людям нравится использовать его и для администратора.
2) Вы можете изменить свои хранимые процедуры, чтобы они принимали идентификатор пользователя в качестве параметра.
1) Рекомендуется, чтобы ваше веб-приложение обычно использовало один вход в базу данных. Если вы этого не сделаете, вам придется выдавать себя за своего абонента, что обычно не рекомендуется и не очень хорошо масштабируется. Не следует использовать разные строки подключения для каждого пользователя. Например, использование аутентификации SQL для каждого пользователя - плохая идея. Это сделает опрос соединения неэффективным.
2) Вы можете сделать это, изменив строку подключения, но это сделает опрос подключения неэффективным.
Is it recommended practice that all database access from an asp.net app would all share a single database login?
Да, в первую очередь для пула соединений.
Что касается пункта 2), я обычно делаю это, регистрируясь на стороне ASP.NET.
С точки зрения передового опыта .NET, вы можете рассмотреть возможность взглянуть на Корпоративная библиотека Microsoft. Он содержит набор практик, шаблонов и функций, которые помогают решать такие проблемы, как безопасность и доступ к данным.
Я бы обычно использовал одного пользователя для пула соединений.
В том случае, когда вам может понадобиться отследить конкретного пользователя. Я пишу в функции администратора, где вы можете заставить приложение использовать второй вход в базу данных. Затем вы можете включить это для конкретного пользователя и отслеживать этого пользователя индивидуально.
Это просто означает, что вы получаете возможность трассировки как разовую, сохраняя при этом пул однопользовательских подключений для остальной части приложения.
Я тоже использую тот же подход. В последнее время мне интересно, влияет ли это на масштабируемость приложения. Мои серверы БД имеют многоядерные процессоры и вполне способны выполнять параллельные операции, но я думаю, что SQL Server сериализовал запросы, выполняемые с одним и тем же идентификатором пользователя. Я думаю, это означает, что хранимые процедуры от разных реальных пользователей помещаются в очередь, потому что SQL Server видит, что все они исходят от одного и того же идентификатора пользователя.
Если это так, я бы подумал, что это серьезно ограничит масштабируемость моего приложения, не так ли?
>> Вы можете изменить свои хранимые процедуры, чтобы они принимали идентификатор пользователя в качестве параметра. Я подумал об этом для будущих проектов, но не для уже существующей кодовой базы.