02 июня 2020 года    
Вторник | 12:11    
Главная
 Новости
Базы данных
Безопасность PC
Всё о компьютерах
Графика и дизайн
Интернет-технологии
Мобильные устройства
Операционные системы
Программирование
Программы
Связь
Сети
 Документация
Статьи
Самоучители
 Общение
Форум







Разделы / Интернет-технологии / ASP.NET

Использование доверенных (trusted) соединений в ASP.NET

Использование доверенных (trusted) соединений в ASP.NET 
Автор: Василий Петрухин

Использование жестко заданных паролей в веб приложении не всегда желательно. Microsoft SQL Server предоставляет возможность использовать «доверенные соединения» (trusted connections) для аутентификации соединения с БД. В этом случае по сети передается только имя пользователя и так называемый маркер аутентификации (authentication token). Пароль пользователя по сети не передается. При попытке использования доверенных соединений в приложении ASP.NET, можно натолкнуться на некоторые сложности связанные с особенностями работы ASP.NET. В частности это связано с настройками учетной записи под которой функционирует рабочий процесс ASP.NET.

  • В Windows 2000 (IIS 5.0) и Windows XP (IIS 5.1) ASP.NET работает в контексте локальной учетной записи ASPNET.
  • Windows Server 2003 использует IIS 6.0 с новой концепцией пулов приложений (Application pools) и ASP.NET работает в контексте учетной записи «NT AUTHORITY\NETWORK SERVICE»

Если веб-сервер IIS 5.x и SQL Server находятся на одном компьютере, тогда использование доверенного соединения не представляет проблем - достаточно дать нужные права пользователю ASPNET на объекты БД и добавить в строку соединения «Integrated Security=SSPI» или «Trusted_Connection=true». Строка соединения может, например, выглядеть следующим образом:


Data Source=(local);Initial Catalog=MSPetShop;Integrated Security=SSPI;

В случае когда SQL Server работает на одном компьютере вместе с IIS 6 для получения доступа к БД добавьте локальную группу IIS_WPG в список учетных записей SQL Server и предоставьте ей нужные права доступа к объектам БД. Способ аутентификации на SQL Server должен быть mixed (SQL Server and Windows).

Большую сложность представляет случай, когда SQL Server и IIS/ASP.NET находятся на разных компьютерах, так как в этом случае на SQL сервере нет учетной записи ASPNET или группы IIS_WPG.

Существуют следующие способы решения этой проблемы:

  1. Запускать ASP.NET под учетной записью домена
  2. Использование явно заданных имени пользователя и пароля
  3. Использование имперсонализации
  4. Создание копии учетной записи ASPNET на SQL Server (для IIS 5.x)
  5. Создание собственного пула приложений в IIS6

Запуск любого веб-приложения под учетной записью домена является опасной практикой. В случае успешной атаки на веб-сервер злоумышленник получит доступ ко всей нашей локальной сети в контексте аутентифицированного пользователя домена.

Способ №4 (явно заданные имя пользователя и пароль) в контексте данной статьи нас не устраивает. Тем не менее, отметим, что строку соединения можно хранить не только в файле web.config, но и в реестре. Подробно этот способ описан в базе знаний Microsoft под номером 329290 и в MSDN в статье «Building Secure ASP.NET Applications».

Имперсонализация

Процесс имперсонализации позволяет запускать ASP.NET под отдельной учетной записью, отличной от стандартной. На обоих компьютерах необходимо создать учетные записи с одинаковыми именами и паролями. На компьютере с IIS учетная запись должна иметь достаточные права для работы ASP.NET, подробно описанные в MSDN. На компьютере с SQL Server этой учетной записи должны быть выданы необходимые права на объекты БД.

Следующий шаг - это настройка ASP.NET на запуск от имени созданной учетной записи. Это можно сделать двумя способами: явным указанием имени и пароля в файле web.config или одновременным изменением настроек в IIS Manager и редактированием web.config.

Чтобы явно указать имя и пароль от имени которой будет работать ASP.NET добавим секцию <identity> в файл web.config


<system.web>
    <identity impersonate="true"
      userName="yourNewUsername"
      password="yourStrongPassword"
    />
</system.web>

Такой способ мешает достижению нашей цели - не указывать явно пароли в настройках приложения.

Так как мы не хотим явно указывать пароль в web.config, то удалим из приведенной конфигурации имя пользователя и пароль, тем самым позволив IIS самому указывать от имени какой учетной записи запускать рабочий процесс ASP.NET. Секция <identity> в web.config тогда будет выглядеть так:


<system.web>
    <identity impersonate="true" />
</system.web>

Теперь запустим IIS Manager и откроем свойства корневой папки нашего приложения, перейдем на закладку «Directory Security», нажмем «Edit...» и в появившемся диалоге укажем имя пользователя и пароль.

Смена контекста запуска ASP.NET в IIS 5.x (Windows 2000/XP)

В IIS 5 можно сменить учетную запись для всех приложений ASP.NET, что позволит избежать ручного редактирования файла web.config для каждого приложения. Как было упомянуто выше ASP.NET под IIS5 работает в контексте учетной записи ASPNET. Эта учетная запись уже обладает всеми нужными правами, но мы не знаем ее пароля, который был задан при установке. Однако, мы можем установить новый пароль, одновременно создав на SQL сервере учетную запись ASPNET с таким же паролем. Теперь нужно изменить глобальный файл конфигурации machine.config в каталоге «\windows\microsoft.net\framework\номер.версии\config», а именно директиву processmodel


<processmodel
  ...
  userName="ASPNET" password="ASPNETpassword"
  ...
/>

И наконец перезапустить IIS командой: iisreset /restart

Создание собственного пула приложений в IIS6

Для IIS6 самым оптимальным способом является создание собственного пула приложений. Пул представляет собой выделенный рабочий процесс IIS, внутри которого размещаются отдельные приложения. Для каждого пула можно устанавливать параметры производительности, контроля работоспособности и, что наиболее важно в рамках этой статьи, учетную запись, в контексте которой запускаются приложения. Нам снова понадобится создать одинаковые учетные записи на веб-сервере и сервере БД. Для создания нового пула приложений запустим IIS Manager, щелкнем правой кнопкой мыши на элементе «Application Pools» и выберем в контекстном меню команду «New -> Application Pool...». Введем имя нового пула и нажмем ОК. Теперь откроем свойства нового пула через контекстное меню, перейдем на закладку «Identity» и введем имя и пароль ранее созданной учетной записи. Теперь надо указать приложению использовать новый пул. Раскроем ветку «Web Sites», выберем каталог приложения, откроем диалог со свойствами, перейдем на закладку «Home Directory» и выберем нужный пул в выпадающем списке «Application Pool».

Побочные эффекты

Использование доверенных соединений имеет и свои побочные эффекты. Если соединения открываются под разными учетными записями, то такие соединения не попадают в пул соединений. Это увеличивает нагрузку и на IIS и на SQL Server. Доверенные соединения также требуют больше вычислительных ресурсов в процессе аутентификации, по сравнению с SQL аутентификацией, так как проверка подлинности имени пользователя происходит системной службой Windows вне процесса SQL сервера. При использовании учетных записей домена дополнительная нагрузка также ложится на контроллеры домена. В любом случае обязательно проводите стресс-тестирование своих приложений перед развертыванием!

Заключение

Не существует единственного «правильного» способа использования доверенного соединения в ASP.NET. Вы можете выбирать из нескольких способов в зависимости от требований и нужд своего приложения.

Использование доверенных (trusted) соединений в ASP.NET
Лента новостей


2006 (c) Copyright Hardline.ru