Використання жорстко заданих паролів в веб додатку не завжди бажано. Microsoft SQL Server надає можливість використовувати «довірені з'єднання» (trusted connections) для аутентифікації з'єднання з БД. В цьому випадку по мережі передається тільки ім'я користувача і так званий маркер аутентифікації (authentication token). Пароль користувача по мережі не передається. При спробі використання довірених сполук в додатку ASP.NET, можна натрапити на деякі складності пов'язані з особливостями роботи ASP.NET. Зокрема це пов'язано з настройками облікового запису під якою функціонує робочий процес ASP.NET.
Якщо веб-сервер IIS 5.x і SQL Server знаходяться на одному комп'ютері, тоді використання довіреної з'єднання не представляє проблем - достатньо дати потрібні права користувачеві ASPNET на об'єкти БД і додати в рядок з'єднання «Integrated Security = SSPI» або «Trusted_Connection = true» . Рядок з'єднання може, наприклад, виглядати наступним чином:
У разі коли SQL Server працює на одному комп'ютері разом з IIS 6 для отримання доступу до БД додайте локальну групу IIS_WPG в список облікових записів SQL Server і надайте їй потрібні права доступу до об'єктів БД. Спосіб аутентифікації на SQL Server повинен бути mixed (SQL Server and Windows).
Велику складність представляє випадок, коли SQL Server і IIS / ASP.NET знаходяться на різних комп'ютерах, так як в цьому випадку на SQL сервері немає облікового запису ASPNET або групи IIS_WPG.
Існують наступні способи вирішення цієї проблеми:
- Запускати ASP.NET під обліковим записом домену
- Використання явно заданих імені користувача та пароля
- Використання імперсоналізаціі
- Створення копії облікового запису ASPNET на SQL Server (для IIS 5.x)
- Створення власного пулу додатків в IIS6
Запуск будь-якого веб-додатки під обліковим записом домену є небезпечною практикою. У разі успішної атаки на веб-сервер зловмисник отримає доступ до всієї нашої локальної мережі в контексті аутентифицированного користувача домену.
Спосіб №4 (явно задані ім'я користувача і пароль) в контексті даної статті нас не влаштовує. Проте, відзначимо, що рядок з'єднання можна зберігати не тільки в файлі web.config, але і в реєстрі. Детально цей спосіб описаний в базі знань Microsoft під номером 329290 і в MSDN в статті «Building Secure ASP.NET Applications».
Імперсоналізація
Наступний крок - це настройка ASP.NET на запуск від імені облікового запису. Це можна зробити двома способами: явним зазначенням імені та пароля у файлі web.config або одночасною зміною налаштувань в IIS Manager і редагуванням web.config.
Щоб явно вказати ім'я та пароль від імені якої буде працювати ASP.NET додамо секцію
Такий спосіб заважає досягненню нашої мети - не вказувати явно паролі в налаштуваннях програми.
Так як ми не хочемо явно вказувати пароль в web.config, то видалимо з наведеної конфігурації ім'я користувача і пароль, тим самим дозволивши IIS самому вказувати від імені якої облікового запису запускати робочий процес ASP.NET. секція
Тепер запустимо IIS Manager і відкриємо властивості кореневої папки нашого застосування, перейдемо на закладку «Directory Security», натиснемо «Edit. »І в діалозі вкажемо ім'я користувача і пароль.
І нарешті запустити 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. Ви можете вибирати з декількох способів залежно від вимог і потреб свого застосування.