ایجاد یک ارتباط امن با SQL Server در ASP.NET

نگهداری صریح رمزعبور و Hard Code نمودن آن در برنامه های کاربردی و وب سایتها قابل قبول نمی

باشد. SQL Server داری امکانی با عنوان Trusted Connection می باشد که از طریق آن اعتبار

سنجی لازم برای دسترسی به منابع SQL Server از روی نام Login انجام می شود. در این حالت

هیچ رمز عبوری به SQL Server فرستاده نمی شود و تنها نام Login و یک Authentication Token به

آن ارسال می گردد. در صورتیکه شما خواسته باشید از این امکان در ASP.NET استفاده نمایید در

پاره ای از موارد تا حدودی با مشکل مواجه خواهید شد. زیرا کاربری که ASP.NET تحت حقوق

دسترسی آن اجرا می شود نقش تعیین کننده ای را ایفا می کند. در حالت پیش فرض ASP.NET با

استفاده از کاربر ASPNET در ماشین محلی اجرا می گردد. در صورتیکه ASP.NET و SQL Server هر

دو برروی یک ماشین اجرا شوند کار بسیار ساده می باشد. در این حالت باید به کاربر ASPNET در

SQL Server حقوق دسترسی و مجوزهای لازمه اعطا گردیده و در نهایت در رشته Connection لازم

است عبارت Integrated Security=SSPI یا Trusted_Connection=true بر حسب سبک رشته

Connection در نظر گرفته شود.
مشکل زمانی رخ می دهد که ASP.NET و SQL Server برروی ماشینهای جداگانه ای اجرا گردند که در

واقع در اکثر موارد نیز چنین می باشد. زیرا کاربر ASPNET در SQL Server قابل دسترسی نمی باشد.
پنج راه اصلی برای غلبه بر این مشکل موجود می باشد.

استفاده از IIS 6 در حالت Native Application
انطباق کاربر ASP.NET برروی IIS و SQL Server و مشخص کردن رمز عبور.
استفاده از جعل هویت (Impersonation) بمنظور تغییر کاربر ASP.NET.
کد کردن (Encrypt) رشته Connection و قرار دادن آن در رجیستری و فراموش کردن ارتباط امن!
تغییر کاربر ASP.NET به یک Domain User.


اجرای هر نوع سرویس وب به عنوان Domain User بسیار خطرناک می باشد. زیرا در این صورت

هکرها با استفاده از حقوق دسترسی کاربر دامنه قابلیت دسترسی به تمامی منابع داخل و خارج

سرویس دهنده وب را دارا می باشند.
کد کردن داده ها و دسترسی به آنها بطور کامل در مقاله شماره Microsoft Knowledge Base 329290

و مقاله Building Secure ASP.NET Applicartion در MSDN بررسی شده است.
هر دو حالت انطباق کاربر و جعل هویت نیازمند این می باشد که شما داری حسابهای Mirror در IIS و

SQL Server باشید. ( در صورتیکه شما در یک محیط Active Directory و Domain قرار نداشته باشید)
جعل هویت

جعل هویت به شما این امکان را می دهد که به ASP.NET بگویید تحت عنوان یک کاربر بخصوص اجرا

شود. برروی هر دو ماشین مورد نظر کاربری همنام و با رمز عبور مطمئن ایجاد نمایید. برروی سرویس

دهنده IIS کاربر ایجاد شده باید دارای توانایی اجرا به عنوان کاربر ASP.NET را دارا باشد (برای

اطلاعات بیشتر می توانید به MSDN مراجعه نمایید). برروی سرویس دهنده SQL Server نیز کاربر

مورد نظر باید قابلیت دسترسی به منابع مورد نظر از جمله بانک اطلاعاتی، جداول، دیدگاهها،

روالهای ذخیره شده و … را داشته باشد.
اکنون شما می بایست ASP.NET را بمنظور اجرا تحت عنوان این کاربر پیکره بندی نمایید. دو راه حل

بمنظور انجام این عمل در پیش روی شما می باشد. راه اول قرار دادن رمز عبور در فایل Web.Config

(که راه نامطلوبی است) و دومین راه استفاده از ابزار IIS Administration همراه تنظیماتی در فایل

Web.Config.
برای Hard Code کردن رمز عبور و نام کاربر فایل Web.Config را ویرایش کرده و حالت عنصر identity را

بصورت زیر به آن اضافه نمایید.
<system.web>

<identity impersonate=”true”
userName=”yourNewUsername”
password=”yourStrongPassword”/>

</system.web>


این حالت در واقع تمامی تلاش شما برای قرار ندادن رمز عبور در کد را بی نتیجه خواهد کرد.
در صورتیکه شما نیاز داشته باشید که رمز عبور را در کد قرار ندهد (که باید همین طور باشد) می

توانید از قرار دادن نام کاربر و رمز عبور در فایل Web.Config صرفه نظر کرده و تنظیمات مربوطه را در

IIS انجام دهید. اما نیاز است شما عنصر idenity را بصورت زیر در فایل Web.Config قرار دهید.
<system.web>

<identity impersonate=”true” />

</system.web>


اکنون ابزار IIS Administration را باز کرده و روی شاخه ای که برنامه شما در آن قرار دارد کلیک راست

نمایید. پنجره خصوصیات را باز کرده و در برگه Directory Security دکمه Edit قسمت Autentication

and access control را کلیک نمایید. قسمت Enable anonymous access را تیک زده و نام کاربر و رمز

عبور آنرا مشخص نمایید.
ویرایش محتوی پیش فرض
در صورتیکه شما با IIS 5 کار می کنید و انجام این عمل ممکن است اثرات جانبی داشته باشد و یا

شما داری چندین برنامه می باشید که تعیین کاربر برای تک تک آنها وقت گیر می باشد، در این حالت

می توانید مستقیما محتوی کاربر ASP.NET را تغییر دهید. همانطور که قبلا ذکر شد ASP.NET تحت

کاربر ASPNET اجرا می گردد و این کاربر مجوزهای لازم را برای اجرای صفحات ASP.NET را دارا می

باشد. این کاربر در زمان نصب Framework بطور خودکار ایجاد می گردد و رمز عبور آن برای ما

شناخته شده نیست. تنها عمل ممکن برای ما Rest کردن رمز عبور آن (فراموش نشود کاربر ASPNET

را در SQL Server با همان رمز عبور ثبت نمایید) و سپس ویرایش فایل machine.config و اطلاع به

Framework بمنظور استفاده از این رمز عبور جدید. متاسفانه شما نیاز است که رمز عبور را بصورت

صریح در این فایل ذکر نمایید. این فایل در مسیر زیر قرار دارد.
کد:
c:\windows\microsoft.net\framework\versionNumber\c onfig
بمنظور پیکره بندی مجدد و تعیین رمز عبور جدید عنصر processModel را در فایل فوق پیدا کرده و آنرا

بصورت زیر با جایگزینی های لازم تغییر دهید.
<processmodel

userName=”ASPNET” password=”ASPNETpassword”

/>


پس از انجام این عمل IIS را راه اندازی مجدد نمایید.
IIS 6 در حالت محلی
آخرین راه و در واقع بهینه ترین راه استفاده از IIS 6 و اجرای برنامه های ASP.NET در حالت محلی

می باشد. IIS 6 به شما امکان ایجاد Application Pool را می دهید. یک Pool، کنترل کارایی، چرخه

پروسه ها و مهمتر از همه امنیت لازم برای ایجاد ارتباط امن را فراهم می کند. در این حالت شما

همانند حالت قبل نیازمند ایجاد یک کاربر برروی IIS و SQL Server می باشید. برای ایجاد یک Pool

ابزار IIS Administration را فعال کرده برروی Application Pool کلیک راست کرده و گزینه New

Application Pool را انتخاب نمایید. نامی برای Pool خود انتخاب کرده و دکمه OK را کلیک نمایید.

سپس برروی نام Pool ایجاد شده راست کلیک کرده و گزینه Properties را انتخاب نمایید. با انتخاب

برگه Identity نام کاربر و رمز عبور آنرا مشخص نمایید. در ادامه شما نیازمند تغییر تنظیمات برنامه

خود برای استفاده از Pool ایجاد شده می باشد. بدین منظور برروی نام برنامه خود در IIS راست

کلیک کرده و گزینه Properties را انتخاب نمایید. در پنجره Properties برگه Home Directory را انتخاب

کرده وسپس Application Pool آنرا مطابق Pool ایجاد شده تغییر دهید.
تاثیرات جانبی

در استفاده از ارتباط امن با اثراتی جانبی مواجه می باشیم. اگر هر ارتباط تحت کاربرانی مجزا باز

شده باشند در این حالت ارتباطات ایجاد شده بین کاربران به اشتراک گذاشته نخواهند شد. این عمل

سرباری برروی IIS و SQL Server ایجاد خواهد کرد. ارتباط امن در مقایسه با حالت دیگر قدرت

پردازشی بیشتری را طلب می کند زیرا درخواست ها خارج از SQL Server و تحت نظارت NT انجام

می پذیرد. در صورتیکه شما از داخل یک دامنه این اعمال را انجام دهید سربار بیشتری برروی کنترل

کننده های دامنه و SQL Server اعمال خواهد شد.
خلاصه

در واقع یک راه واحد برای ایجاد ارتباط امن با SQL Server در ASP.NET وجود ندارد. Microsoft راههای

مختلفی برای رسیدن به این منظور فراهم آورده است و انتخاب بهترین راه برای برنامه شما بر عهده

خود شما می باشد.