ASP.NET Application Connection String и безопасность и разрешения SQL Server

Question

Я развертываю базу данных ASP.NET и базу данных SQL Server (2008) на сервере в реальном времени (производства). Физический сервер работает как с SQL Server 2008, так и с IIS 7 - он предоставляется хостинговой компанией и составляет , но не является частью нашей внутренней сети.

У меня есть пара вопросов, касающихся безопасности базы данных и строки подключения для приложения ASP.NET.

Раньше я хотел бы создать пользователь базы данных и указать т.д. разрешения SELECT/INSERT для каждой таблицы - но проблема в том, что есть 50+ таблицы в этой базе данных, таким образом это займет много времени ,

Для каждого приложения требуется приложение SELECT/INSERT/DELETE/UPDATE.

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

Кроме того, как бы изменение строки соединения?

Я просто искал какой-то эксперт советы, просто кто-то мне точку в правильном направлении и ссылку на какой-документации о том, как достичь лучшего способа сделать это.

Большое спасибо.

Answer 1

У вас есть по существу три несвязанных вопроса в вашем списке пули, а не один.

• Первый вариант лучше подходит для ServerFault.com, так как он имеет дело с SQL Server, не обязательно вопрос программирования.
  • Однако Google окупилась, а вот способ сделать это: http://www.tech-recipes.com/rx/2298/sql_server_2005_easily_grant_select_all_tables_views/
  • В качестве альтернативы, вы можете просто присвоить пользователю правильные группы, как описано в @ ответ Одед здесь: TSQL granting read and write permissions to all tables
• Для второго, Integrated Security, да, есть способ использования интегрированной безопасности с ASP.NET. См. Эту статью: http://msdn.microsoft.com/en-us/library/bsz5788z.aspx
  • Самый большой недостаток заключается в том, что его больше настроить. это нестандартная (но поддерживаемая) конфигурация, поэтому программисты по обслуживанию, возможно, раньше не видели настройки.
  • Также, если вы это делаете, могут возникнуть проблемы с безопасностью, если вы используете учетную запись с разрешениями в другом месте. Обязательно соблюдайте принцип наименьших привилегий.Лучше всего создать учетную запись домена специально для каждого веб-сайта, поэтому, если вы станете жертвой компрометации, она ограничит ущерб, который может быть нанесен. Вы знаете, что ваши проблемы безопасности лучше, чем я, поэтому это может быть или не быть релевантным советом, но это нужно учитывать.
  • Наконец, (и это, вероятно, слишком очевидно, чтобы указать) было бы глупо использовать UserId реального человека. Если этот человек покинет компанию и их учетная запись будет удалена, веб-сайт, очевидно, сломается.
• Теперь, когда я нашел ответ на первый вопрос, третий становится спорным.

Answer 2

Вы можете создать или использовать существующую роль базы данных. Затем вы помещаете пользователя в эту роль, чтобы позволить этому пользователю иметь все необходимые разрешения. Например, вы можете поместить учетную запись пользователя, которую вы используете в своем соединении, в роль db_datawriter, учитывая описанные вами сценарии.

См http://msdn.microsoft.com/en-us/library/ms189121%28v=sql.105%29.aspx

Эта статья также связана с тем, как вы могли бы поднять разрешения пользователя.

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