تحقیق امنیت پایگاه داده

فهرست مطالب

فصل 1 کلیات 3
فصل 2 امنیت کلاسیک 6
2-1 مقدمه 6
2-2 امنیت پایگاه داده 7
2-3 تهدید امنیت در پایگاه داده 7
2-4 کنترل امنیت پایگاه داده 8
2-4-1 کنترل انتشار 8
2-4-2 کنترل استنباط 8
2-4-3 کنترل دسترسی 9
2-4-3-1 ارتباط کنترل دسترسی با سایر سرویس های امنیتی 12
2-4-3-2 ماتریس دسترسی 14
2-4-3-3 سیاست های کنترل دسترسی 15
2-4-3-3-1 سیاست تشخیص 16
2-4-3-3-2 سیاست اجباری 18
2-4-3-3-3 سیاست مبتنی بر نقش 22
2-5 مدیریت تفویض اختیار 24
2-6 جمع بندی 25
فصل سوم بررسی امنیت در نرم افزار SQLServer2005 26
3-1 مقدمه 26
3-2 هویت شناسی 27
3-2-1 مد هویت شناسی ویندوزی (WAM) 27
3-2-2 مد ترکیبی (MM) 28
3-3 Logins 30
3-3-1 Login های ویندوز و کاربران پایگاه داده 30
3-3-1-1 ایجاد گروه در ویندوز 30
3-3-1-2 ارتباط گروه های ویندوز با کاربران SQLServer با استفاده از GUI 32
3-3-1-3 ارتباط گروه های ویندوز با کاربران SQLServer با استفاده از کد های T-SQL 36
3-3-2 Login های سرویس دهنده و کاربران پایگاه داده 38
3-3-2-1 ایجاد Login در سطح سرویس دهنده با استفاده از GUI 38
3-3-2-2 ایجاد Login در سطح سرویس دهنده با استفاده از کد T-SQL 40
3-3-3 Sa Login 40
3-4 کنترل دسترسی(Access Control) 41
3-5 نقش ها 42
3-5-1 نقش های ثابت سرویس دهنده (FSR) 42
3-5-2 نقش های پایگاه داده ای (DBR) 44
3-5-3 نقش های برنامه ای (APR) 50
3-6 شِما 53
3-7 Principal 55
3-8 Securable 56
3-9 Permission 57
3-10 رمز نگاری 60
3-10-1 رمزنگاری با استفاده از کلمه عبور کاربر 61
3-10-2 رمزنگاری کلید متقارن 62
3-10-3 رمزنگاری کلید نامتقارن 63
3-10-4 رمزنگاری با استفاده از گواهینامه 64
3-11 جمع بندی 66
فصل چهارم طراحی سیستم پرسنلی 67
4-1 مقدمه 67
4-2 UseCase 68
4-2-1 شرح UseCase 68
4-3 نمودار توالی 70
4-4 Class Diagram 74
4-5 واژه نامه داده ای 74
فصل پنجم معرفی نرم افزار و بررسی موانع هنگام برنامه نویسی 76
5-1 مقدمه 76
5-2 رشته ارتباط 77
5-3 ارتباط برنامه با نقش برنامه ای(APR) 78
5-4 معرفی فرم پرسنل 83
5-5 رمز نمودن اطلاعات 87
5-6 کار با استثناها 88
5-7 جمع بندی 92
فصل ششم نتیجه گیری و راهکارهای آینده 93
منابع و ماخذ 95

فصل 1 کلیات

امنیت اطلاعات یکی از مهمترین مفاهیم ،از آغاز زندگی بشر تاکنون بوده است. انسان های ادوار گذشته از اهمیت این موضوع مطلع بودند و بسیاری از شکست های انسان های گذشته در جنگ ها فاش شدن اطلاعات مهم و سری بوده است. در ضمن آنها اطلاعات حساس را به رمز تبدیل کرده و برای رد و بدل کردن این اطلاعات از زبان رمزی استفاده می کردند.
با پیشرفت علم و جوامع بشری اهمیت این موضوع بیش از پیش آشکار شده و فاش شدن اطلاعات نظامی و یا سیاسی ممکن است منجر به نابودی یک جامعه بیانجامد. سرقت های میلیاردی که گاها از بانک ها می شود مثالی دیگر از اهمیت این موضوع است.
برای امن کردن جامعه مدرن باید از امکانات مدرن نیز استفاده شود زیرا سارقان اطلاعات از امکانات پیشرفته برای دستیابی به اطلاعات استفاده می کنند. در این پایان نامه به بررسی امنیت در محیط پایگاه داده می پردازیم. این محیط بر مشکلاتی نظیر افزونگی داده و ناسازگاری داده که در سیستم فایل مشکل ساز بوده ، فائق آمده و با به اشتراک گذاشتن داده ها ، امکان استفاده بیشتر از اطلاعات را مهیْا ساخته است. در این محیط امکان مدیریت تعداد زیادی کاربر تعبیه شده است. کاربر زیاد مساوی است با درد سر زیاد ! ممکن است کاربری عمدی یا غیر عمدی به داده های محرمانه دست یابد و سیستم را مختل سازد. برای تامین امنیت در چنین محیط هایی که همواره با پیچیدگی های زیادی نیز برخوردار است لازم است در ابتدا موضوع امنیت را بصورت کلاسیک بررسی کنیم. آشنایی با مفاهیمی همچون تهدید ، صحت داده و انتشار داده ، ما را در شناخت مدل های امنیت یاری می کند. تامین امنیت در پایگاه داده با شناسایی تهدید آغاز می شود. از دیگر واژه های مهم در این موضوع کنترل دسترسی است. هدف کنترل دسترسی محدود کردن فعالیت هایی است که کاربر مجاز می تواند بر روی سیستم های کامپیوتری انجام دهد. کنترل دسترسی شامل سیاست های مختلفی است. سیاست های تشخیص ، اجباری و مبتنی بر نقش از آن جمله هستند. این سیاست ها هر یک با اعمال محدودیتی خاص دسترسی کاربر را محدودتر می کنند و در تناقض با یکدیگر نیستند ،به عبارت دیگر جهت حرکت همه آنها یکی است.
امنیت کلاسیک را در فصل 2 بررسی می کنیم. سپس به بررسی امنیت در نرم افزار SQLServer2005 می پردازیم. رنگ امنیت کلاسیک در تمامی مولفه های امنیتی SQLServer2005 به چشم می خورد. در این فصل با مفاهیمی همچون مدل هویت شناسی و تفویض اختیار در SQLServer2005 آشنا می شویم. انواع کنترل دسترسی ، انواع نقش ها ، شما و بسیاری دیگر از واژه ها و مفاهیم را در فصل 3 بررسی می کنیم. رمز نگاری که در نسخه SQLServer2000 نبوده به SQLServer2005 اضافه شده و این نرم افزار را از لحاظ امنیت بسیار پرقدرت ساخته است. در واقع در فصل 3 مدل امنیتی SQLServer2005 به طور کامل بررسی شده است. در فصل 4 یک محیط عملی طراحی و پیاده سازی شده است. در فصل 5 بامشکلاتی که در حین پیاده سازی چنین سیستمی با آن مواجه هستیم را بررسی می کنیم. اهمیت این پایان نامه از این جهت است که تعداد بسیار کمی از افراد متخصص این موضوع را در SQLServer2005 بررسی کرده و آن را بصورت عملی پیاده سازی کرده اند. بسیاری از سیستم های طراحی شده از لحاظ امنیتی ناکارامد هستند و مکانیزم های امنیتی به کار رفته در این سیستم ها دارای نواقص و کمبودهای بسیاری است.

فصل 2 امنیت کلاسیک

2-1 مقدمه
در محیط پایگاه داده ، برنامه ها و کاربران مختلف سازمان به یک مجموعه اطلاعات واحد و یکپارچه در DBMS دسترسی دارند. مشکلاتی نظیر ناسازگاری و افزونگی داده ها که در سیستم های گذشته نمایان بودند از بین رفته و در عوض مساله تامین امنیت در پایگاه داده اهمیت بسیاری پیدا کرده است. تامین امنیت در محیط پایگاه داده یعنی شناسایی تهدید هایی1 که امنیت آن را به خطر می اندازند و همچنین انتخاب سیاست ها و مکانیسم های مناسب برای مقابله با آن. یکی از راههای مبارزه با تهدید ها ، کنترل دسترسی است. هدف کنترل دسترسی2، محدود کردن اعمال و فعالیت هایی است که کاربر مجاز ، می تواند بر روی سیستم کامپیوتری انجام دهد. کنترل دسترسی ، آنچه را که کاربر و یا برنامه تحت کنترل او می تواند انجام دهد را کنترل می کند. در این راستا ، کنترل دسترسی ، مانع از انجام فعالیت هایی می شود که امنیت سیستم را تهدید می کنند.
در این فصل پس از بیان چند مفهوم پایه در رابطه با امنیت پایگاه داده ، به بررسی کنترل دسترسی و رابطه آن با سایر سرویس های امنیتی از جمله سرویس هویت شناسی3، سرویس حسابرسی4 و سرویس مدیریت5 می پردازیم. سپس ماتریس دسترسی6 و چگونگی پیاده سازی آن در محیط های کاربردی را بررسی می کنیم. در پایان به مطالعه سیاست های کنترل دسترسی و مختصری درباره چگونگی مدیریت آنها می پردازد.
2-2 امنیت پایگاه داده
امنیت اطلاعات در پایگاه داده دارای سه بخش اصلی است :
محرمانگی7 : تضمین محرمانگی اطلاعات شامل جلوگیری از فاش شدن غیر مجاز اطلاعات و شناسایی و تحذیر عوامل آن می باشد.
صحت8 : تضمین صحت اطلاعات شامل جلوگیری از تغییر غیر مجاز اطلاعات و شناسایی وتحذیر عوامل آن می باشد.
دسترس پذیری : تضمین در دسترس پذیری اطلاعات شامل جلوگیری از رد غیر مجاز دسترسی به سرویس های ارائه شده توسط سیستم و شناسایی و تحذیر عوامل آن می باشد.

2-3 تهدید امنیت در پایگاه داده
در اینجا لازم است تا تعریف مناسبی از تهدید در پایگاه داده ارائه شود. تهدید به معنی تجاوز تصادفی ، یا عمدی و برنامه ریزی شده به پایگاه داده ، به منظور فاش سازی و یا تغییر اطلاعات مدیریت شده توسط سیستم می باشد. تجاوز به پایگاه داده و تهدید امنیت آن شامل خواندن ، تغییر و حذف غیر مجاز و نادرست اطلاعات می باشد. عوامل ایجاد کننده تجاوز در پایگاه داده تهدید نامیده می شوند. نتایج تجاوز به پایگاه داده مختصرا در ذیل آورده شده است :
انتشار نامناسب اطلاعات9 : خواندن عمدی و یا غیر عمدی اطلاعات توسط کاربر غیر مجاز که موجب انتشار غیر مجاز اطلاعات می شود.
تغییر نامناسب داده10 : تغییر نامناسب داده شامل تمام تجاوز هایی می شود که صحت داده را به خطر می اندازند.
عدم پذیرش سرویس ها : عدم پذیرش سرویس ها شامل تمام اعمالی است که مانع دسترسی کاربر به داده ها و یا استفاده از منابع می شود.

2-4 کنترل امنیت پایگاه داده
امنیت پایگاه داده از طریق کنترل انتشار11 ، کنترل استنباط12 و کنترل دسترسی13 اعمال می شود که به بررسی آنها می پردازیم :
2-4-1 کنترل انتشار
کنترل انتشار ، انتقال اطلاعات میان منابع را کنترل می کند. یک انتشار میان منابع X و Y هنگامی رخ می دهد که اطلاعاتی از X خوانده شده و در Y نوشته شود. کنترل انتشار ، از انتقال داده های موجود در منابع سطح بالا به منابع سطح پایین جلوگیری می کند.
2-4-2 کنترل استنباط
منظور از استنباط یعنی دستیابی به اطلاعات محرمانه از روی داده های غیر محرمانه است. مساله استنباط از داده ها بیشتر در پایگاه داده های آماری اتفاق می افتد. در این نوع پایگاه داده ها کاربر باید از بازگشت به عقب و نتیجه گیری از روی داده های آماری بر حذر داشته شود. به عنوان مثال فرض کنید کاربری طی یک پرس و جو14 متوسط حقوق کارمندان زن را در سازمان رویت کند. سپس این کاربر، تعداد کارمندان زن را در سازمان مورد پرس و جو قرار می دهد. اگر نتیجه بدست آمده از آخرین پرس و جو عدد یک باشد ، این کاربر قادر خواهد بود حقوق این کارمند زن را استنباط کند.
2-4-3 کنترل دسترسی
مسئولیت کنترل دسترسی در قبال داده های موجود در سیستم این است که تمام دسترسی های مستقیم به منابع سیستم منحصرا بر اساس مد ها و قانون های تعیین شده توسط سیاست های امنیتی15 انجام پذیرد. در یک سیستم کنترل دسترسی(شکل 2-1) ، درخواست کننده16 (کاربر ، فرایند) به منابع17 (داده ، برنامه) از طریق اعمالی نظیر خواندن ، نوشتن و یا اجرا دسترسی پیدا می کند.

شکل 2-1 : سیستم کنترل دسترسی
از لحاظ عملکرد این سیستم از دو قسمت تشکیل شده است :
* مجموعه ای از سیاست ها و قانون ها : اطلاعات ذخیره شده در سیستم بیانگر مد دسترسی می باشد که کاربر به هنگام دسترسی به منابع ملزم به پیروی از آنها است.
* مجموعه ای از رویه های کنترلی (مکانیسم های امنیت): این رویه ها درخواست دسترسی را بر اساس قوانین یاد شده بررسی می کنند. درخواست ها ممکن است مورد پذیرش ، رد و یا تغییر قرار گیرند و داده های غیر مجاز سانسور شوند.
سیاست های امنیتی: سیاست های امنیتی سیستم ، راهبردهایی هستند که با طراحی امنیت سیستم و مدیریت اختیارهای افراد در سیستم ، مرتبط هستند. این سیاست ها بیانگر اصولی18 هستند که بر اساس آنها دسترسی ، اعطا19 و یا رد20 می شوند. قوانین دسترسی21 بیانگر سیاست های امنیتی هستند و رفتار سیستم را در زمان اجرا مشخص می کنند.
سوالی که در اینجا مطرح است این است که چه مقدار از اطلاعات باید در دسترس هر درخواست کننده باشد؟ برای پاسخ به این سوال به بررسی محدودیت های دسترسی22 و دو سیاست پایه می پردازیم:
سیاست کمترین اختیار23 : بر اساس این سیاست به درخواست کننده گان سیستم کمترین مقدار اطلاعاتی را که برای انجام فعالیت های آنها مورد نیاز است ، در اختیار آنها می گذارند. در این سیاست فرض بر این است که امکان تعریف این حد پایین وجود دارد(در اکثر مواقع این کار با دشواری های بسیاری همراه است). ایراد این سیاست این است که ممکن است منجر به محدودیت های بزرگ برای بعضی از درخواست کننده گان شده و مانع فعالیت آنها شود.
سیاست بیشترین اختیار24 : این سیاست برای محیط هایی مانند دانشگاه ها و مراکز تحقیقاتی که محافظت از داده ها اهمیت چندانی ندارد مناسب است. در این محیط ها کاربران قابل اعتماد هستند و در ضمن داده ها باید بین افراد رد و بدل شوند. پس غالبا افراد به بیشتر داده های مورد نیاز خود دسترسی دارند.
از نظر کنترل دسترسی سیستم ها به دو دسته تقسیم می شوند : سیستم های باز و سیستم های بسته.
در یک سیستم بسته25 فقط دسترسی هایی معتبر هستند که صریحا به درخواست کننده اعطا شده باشند. در یک سیستم باز26 دسترسی هایی معتبر هستند که صریحا ممنوع شناخته نشده باشند. بر اساس سیاست های یک سیستم بسته برای هر درخواست کننده باید قانون های دسترسی که بیانگر سطح دسترسی درخواست کننده به منابع سیستم است ، وجود داشته باشند. این سطوح دسترسی معیّن شده برای هر درخواست کننده تنها حقوقی27 هستند که در اختیار وی قرار دارند. بر اساس سیاست های یک سیستم باز برای هر درخواست کننده باید قانون های دسترسی وجود داشته باشند که بیانگر دسترسی غیر مجاز برای درخواست کننده هستند. این دسترسی های غیر مجاز تنها حقوقی هستند که از وی سلب شده است.
سیستم های باز و بسته در انحصار متقابل28 با یکدیگر هستند. تصمیم گیری برای انتخاب یک استراتژی امنیتی ، بر اساس نیازهای پایگاه داده ، کاربران ، برنامه ها و سازمان گرفته می شود. یک سیستم بسته سیاست کمترین اختیار و سیستم باز سیاست بیشترین اختیار را اعمال می کند. حفاظت در سیستم بسته ، قوی تر است زیرا اشتباه در تعریف قوانین دسترسی ممکن است مانع از یک دسترسی مجاز شود ولی باعث خرابی نمی شود در صورتی که در یک سیستم باز چنین اشتباهی ممکن است منجر به دسترسی غیر مجاز و نتیجتا خرابی شود. همانطور که گفته شد انتخاب یکی از این دو سیستم به شرایط بستگی دارد. در محیط هایی که اعطای دسترسی بیشتر از ممنوعیت دسترسی است ، مدیریت سیستم های بسته دشوار است و بهتر است از سیستم باز استفاده شود. در شکل های 1-2 و 1-3 کنترل دسترسی در سیستم های باز و بسته نشان داده شده اند.

شکل 2-2 : کنترل دسترسی در سیستم بسته
اعطا و بازپس گیری اختیارات تنها به عهده یک مدیر نیست. بعضی مواقع مدیریت تفویض اختیار باید بصورت غیر متمرکز و توسط افراد مختلفی انجام شود. در سیستم های توزیع شده که از چندین سیستم محلی تشکیل شده اند مدیریت باید بصورت غیر متمرکز اعمال شود.

شکل 2-3 : کنترل دسترسی در سیستم باز

2-4-3-1 ارتباط کنترل دسترسی با سایر سرویس های امنیتی
کنترل دسترسی به سایر سرویس های امنیت متکی است و با آن ها نوعی همزیستی دارد. وظیفه کنترل دسترسی محدود کردن فعالیت های کاربر مجاز29 می باشد و بوسیله ناظر مرجع30 شروع به کار می کند. ناظر مرجع بصورت یک واسط در بین سیستم و کاربر قرار می گیرد و هر تلاش برای دسترسی کاربر و یا برنامه تحت فرمان او به منابع سیستم ، باید از سد ناظر منابع عبور کند. این ناظر برای تشخیص اینکه آیا کاربر مورد نظر مجاز به انجام فعالیتی می باشد یا خیر ، با یک پایگاه داده تفویض اختیار31 مشاوره می کند. این پایگاه داده ها ، بوسیله یک مدیر امنیت32 ، مدیریت و نگهداری می شود. مدیر امنیت ، این اختیارات را براساس سیاست های موجود در سازمان ، در اختیار افراد مختلف قرار می دهد. البته کاربران ، قادر به تغییر قسمتی از این پایگاه داده هستند ، برای مثال آن ها می توانند در مورد فایل های شخصی خود ، اختیارات مرتبط با سایر کاربران را تغییر دهند. شکل 2-4 ، یک تصویر منطقی از سرویس های امنیت و ارتباط آنها با یکدیگر است. این تقسیم بندی سرویس ها ، ممکن است تا حدی ایده آل بنظر برسد و در بسیاری از سیستم ها بگونه ای که در شکل نشان داده شده است ، پیاده سازی نشود ولی هر چه مدل امنیت سیستم به این تقسیم بندی نزدیک شود ، امنیت سیستم بالا می رود.
حال ، وقت آن فرا رسیده که به بیان تفاوت های میان کنترل دسترسی و سرویس تعیین اعتبار بپردازیم. تعریف دقیق و درست اطلاعات کاربر ، وظیفه سرویس تعیین اعتبار است. کنترل دسترسی فرض می کند که سرویس تعیین اعتبار ، کار خود را بدرستی قبل از اجرایش توسط ناظر منابع انجام داده است. کارایی کنترل دسترسی ، به درستی تعیین هویت کاربر و همچنین به درستی تفویض اختیار بستگی دارد.
دانستن این نکته ضروری است که کنترل دسترسی راه حل کاملی برای برقراری امنیت نیست و باید با سرویس حسابرس همراه باشد. سرویس حسابرس به بررسی و آنالیز تمامی فعالیت ها و درخواست های کاربر در سیستم می پردازد و تمامی آنها را برای بررسی های آینده ثبت می کند.

شکل 2-4 : کنترل دسترسی و سایر سرویس های امنیتی
این سرویس از دو جنبه حائز اهمیت است. اول به عنوان بازدارنده (تمامی درخواست های کاربران ثبت و آنالیز می شود و آنهارا از تخطی کردن مایوس می کند) و دوم با توجه به آنالیز های انجام شده راهها و روزنه های نفوذ تشخیص داده می شوند. در واقع حسابرسی ، این اطمینان را به ما می دهد که کاربران از امتیازات و اختیارات خود سوء استفاده نکنند. توجه به این نکته ضروری است که کارایی سرویس حسابرس ، به کیفیت تعیین هویت بستگی دارد.

2-4-3-2 ماتریس دسترسی
فعالیت ها33، در یک سیستم بوسیله موجودیت هایی با عنوان درخواست کننده آغاز به کار می کنند. درخواست کننده ها کاربران و یا برنامه تحت فرمان کاربران می باشند.در واقع درخواست کننده ها آغازگر فعالیت ها بر روی منابع می باشند. کاربران ممکن است با عناوین متفاوتی ، بسته به اینکه می خواهند از کدامیک از امتیازات34 خود استفاده کنند ، به سیستم متصل شوند. به عنوان مثال ، کاربرانی که بر روی دو پروژه متفاوت فعالیت می کنند ، ممکن است برای کار بر روی هر یک از این پروژه ها به سیستم متصل شوند. در این حالت دو درخواست کننده ، متناظر با این کاربر وجود دارد. درک تفاوت میان در خواست کننده ها و منابع بسیار ضروری و مهم است. در خواست کننده ها آغازگر فعالیتها بر روی منابع می باشند. این فعالیت ها ، با تفویض اختیار به در خواست کننده ها ، داده می شوند. تفویض اختیار ، تحت عنوان حق دسترسی35 و یا مد دسترسی36 بیان می شود. مفهوم حق دسترسی به نوع منبع مورد نظر بستگی دارد. به عنوان مثال در فایل ها حق دسترسی ، شامل خواندن ، نوشتن ، اجرا کردن و مالک بودن می باشد. مفهوم سه حق دسترسی اول مشخص می باشد. مالک بودن به این معنی می باشد که مالک قادر به تغییر دسترسی ها می باشد.
ماتریس دسترسی یک مدل مفهومی است که حق دسترسی هر در خواست کننده را به هر یک از منابع موجود در سیستم ، مشخص می کند. برای هر در خواست کننده یک سطر ، و یک ستون برای هر منبع در این ماتریس وجود دارد. هر سلول این ماتریس ، نشان دهنده این است که آیا درخواست کننده مورد نظر به منبع مورد نظر دسترسی دارد یا نه. شکل1-5 ماتریس دسترسی را نشان می دهد. وظیفه کنترل دسترسی این است که تنها به فعالیت هایی اجازه اجرا دهد که در ماتریس قید شده اند. این عمل به کمک ناظر منابع که واسط بین درخواست کننده و منابع می باشد صورت می گیرد.

شکل2-5 : ماتریس دسترسی
2-4-3-3 سیاست های کنترل دسترسی
سیاست های کنترل دسترسی بیانگر این موضوع هستند که چگونه درخواست کننده ها و منابع را به منظور به اشتراک گذاشتن مد دسترسی بر اساس اختیارات و قوانین حاکم ، گروه بندی شوند. در ضمن این سیاست ها به بررسی چگونگی انتقال حقوق دسترسی می پردازند.
گروه بندی کاربرانی که بعضی از اختیارات و منابع را در دست دارد ، تعیین خصوصیت سیاست ها و پیاده سازی مکانیسم های امنیتی را آسان می کند. چندین معیار مختلف برای گروه بندی پیشنهاد می شود. این گروه بندی ها مشکلات خاص خود را بوجود می آورد. در مرحله طراحی ، مشکلات ناشی از عضویت یک کاربر در چندین گروه متفاوت و در مرحله پیاده سازی مشکل چگونگی مدیریت تغییر عضویت در گروه ها ، بوجود می آید.
در اینجا به بررسی سه سیاست رایج که در سیستم های کامپیوتری استفاده می شوند می پردازیم. این سیاست ها عبارتند از:
سیاست تشخیص37
سیاست اجباری38
سیاست مبتنی بر نقش39
توجه به این نکته ضروری است که سیاست های قید شده فوق ، انحصاری نبوده و با سیاست ها مختلف دیگری می توانند همراه باشند تا یک سیستم امن تر را ایجاد کنند. این مطلب در شکل2-6 نشان داده شده است. هر یک از دوایر داخلی نشان دهنده یک سیاست است که زیر مجموعه ای از مجموعه دسترسی ها را ایجاد می کند. تنها اشتراک این دسترسی ها ، دسترسی مجاز را نشان می دهد. در چنین محیط هایی سیاست ها ، همسو هستند. به این معنی که ناسازگاری وجود ندارد ، بطوری که یک سیاست رویکردی را بپذیرد و سیاست دیگر آن را تحریم کند. در صورت وجود ناسازگاری ، در یکی از مراحل مدیریت ، به بررسی و حلّ و فصل آن می پردازند.

شکل2-6 : سیاست های کنترل دسترسی
2-4-3-3-1 سیاست تشخیص
سیاست تشخیص نیازمند این است که قوانین تفویض اختیار ، سطح اختیار هر درخواست کننده بر روی منابع سیستمی را مشخص کنند. درخواست دسترسی بر اساس مکانیسم های سیاست تشخیص بررسی شده و دسترسی ، تنها برای درخواست کننده هایی مجاز شناخته می شود که برای آنها یک قانون دسترسی موجود باشد(شکل2-7).
سیاست تشخیص بر مبنای اختیارات(قوانین) – که مشخص کننده مد دسترسی(خواندن- نوشتن-اجرا-مالک) هر کاربر به منبع مورد نظر است- و تعیین هویت کاربری که درخواست دسترسی را صادر کرده کار می کند. تشخیص یعنی اینکه امکانی برای کاربر ایجاد شده است تا بتواند حق دسترسی را اعطا و یا لغو کند. هر درخواست کاربر ، برای دسترسی به یک منبع، بر مبنای اختیاراتی که به او داده شده است ، مورد بررسی قرار می گیرد. اگر اختیاری ( کاربرمورد نظر، مجاز به دسترسی به منبع درخواست شده در مد مشخص شده می باشد) ، وجود داشته باشد ، دسترسی مجاز شناخته می شود، در غیر این صورت دسترسی غیر مجاز شناخته شده و کاربر از دسترسی به آن منبع محروم می شود . انعطاف پذیری سیاست تشخیص ، آنرا برای گستره بزرگی از سیستم ها و برنامه ها مناسب ساخته است ، به همین دلیل این سیاست در بسیاری از محیط ها به خصوص در محیط های تجاری و صنعتی پیاده سازی می شود.

شکل 2-7 : سیاست تشخیص کنترل دسترسی
این سیاست نیازمند سیستم تفویض اختیار پیچیده ای است و در ضمن مانع از دست رفتن اطلاعات هنگام واگذاری اختیارات توسط مدیر به افراد مسئول می شود. به هر حال سیاست تشخیص کنترل دسترسی ، دارای نقاط ضعف و کمبودهایی نیز است :
این سیاست اجازه انتقال اطلاعات از منبع قابل خواندن به هر منبع قابل نوشتن را می دهد و امکان کپی اطلاعات از منبعی به منبع دیگر وجود دارد. نتیجتا اطمینان کامل ، از درستی انتشار اطلاعات40در یک سیستم را به ما نمی دهد . به راحتی می توان محدودیت هایی را که به وسیله تفویض اختیار به وجود آمده ، نادیده گرفته شوند. به عنوان مثال کاربری که قادر به خواندن اطلاعات است می تواند بدون اجازه مالک ، آن اطلاعات را در اختیار کاربری که مجاز به این عمل نمی باشد قرار دهد . علت این است که سیاست تشخیص هیچ محدودیتی را برای استفاده از اطلاعاتی که توسط کاربری دریافت شده ، اعمال نمی کند. به عبارتی دیگر انتشار اطلاعات کنترل نمی شود. کنترل بر روی انتشار اطلاعات در سیستم هایی که از سیاست اجباری استفاده می کنند ، اعمال می شود. در این سیستم ها با جلوگیری از انتقال اطلاعات موجود در منابع سطح بالا41 به منابع سطح پایین42 انتشار کنترل می شود.
2-4-3-3-2 سیاست اجباری
در جاهایی که حجم بزرگی از اطلاعات نیاز به امنیت شدید دارد از این سیاست استفاده می شود. نام دیگر این سیاست ، سیاست کنترل انتشار است زیرا مانع از انتشار اطلاعات از منابع سطح بالا به منابع سطح پایین می شود. دسترسی به داده ها از طریق کلاس های امنیتی تعریف شده برای منابع و درخواست کننده ها صورت می گیرد و به هر کاربر و منبع موجود در سیستم ، سطحی از امنیت داده می شود. سطح امنیت متناظر با یک درخواست کننده نشان دهنده درجه اعتمادی است که به او وجود دارد و سطح کلاس بندی متناظر با یک منبع نشان دهنده درجه اهمیت اطلاعات موجود در آن منبع است و یا به عبارت دیگر نشان دهنده پتانسیل آسیب رسی به سیستم در صورت فاش شدن غیر مجاز اطلاعات آن منبع است. در ساده ترین حالت ، سطوح امنیت به صورت سلسله مراتبی43 تعریف می شود.
دو مولفه مهم در کلاس بندی منابع وجود دارد :
سطح کلاس بندی44 : که منعکس کننده سطح اطلاعاتی که آن منبع دارد. این سطوح عبارنتد از :
0 = غیر محرمانه(U)
1 = محرمانه(C)
2 = سری(S)
3 = فوق سری(TS)
طبقه45 : که منعکس کننده دپارتمان های یک سازمان و یا حوزه های سیستمی است. برای مثال در محیط های نظامی این حوزه ها می توانند شامل هسته ای – ناتو – جاسوسی و در محیط های صنعتی شامل تولید – مهندسی – پرسنل – مدیریت باشد. تعداد طبقه های قابل استنتاج برای m حوزه ، 2m می باشد. برای این کلاس های امنیت رابطه هایی بصورت زوج مرتب تعریف می شود که مولفه اول نشان دهنده سطح کلاس و مولفه دوم نشان دهنده طبقه است. دو زوج مرتب SC1=(A1,C1) و SC2(A2,C2) را در نظر بگیرید. رابطه SC1≤SC2 در صورتی برقرار است که A1≤A2 و C2C1 باشد. بنابراین رابطه ((ناتو ، هسته ای) ، 3) ≥ (ناتو ، 2) برقرار است و رابطه (ناتو ، 3) ≥ (( ناتو ، هسته ای ) ، 2 ) برقرار نیست.
البته این طبقه بندی(فوق سری ، سری ، محرمانه و غیر محرمانه) در مورد درخواست کننده ها نیز وجود دارد. رابطه "فوق سری > سری<محرمانه<غیر محرمانه" در بین این طبقات صادق است. هر سطح امنیت ، حق دسترسی به گروه خود و گروه های زیرین خود را دارد. دسترسی به یک منبع به وسیله یک درخواست کننده ، تنها در صورتی مجاز است که سطوح امنیت ، هم در منبع و هم در درخواست کننده برقرار باشد. به طور کلی دو قانون زیر باید برقرار باشد.

شکل2-8 : کنترل انتشار اطلاعات برای تامین محرمانگی
* قانون خواندن : سطح امنیت درخواست کننده باید از سطح امنیت منبعی با قابلیت خوانده شدن ، بالا تر باشد.
* قانون نوشتن: سطح دسترسی درخواست کننده باید از سطح دسترسی منبعی با قابلیت نوشته شدن ، پایین تر باشد.
ارضا این دو قانون از انتقال اطلاعات موجود در منابع سطح بالا به منابع سطح پایین جلوگیری می کند. اثر این قوانین در شکل1-8 توضیح داده شده است. در چنین سیستمی اطلاعات موجود در یک سطح یا در آن سطح منتقل می شوند یا به سطوح بالاتر انتقال می یابند.
در این بخش ضروری است که تفاوت بین درخواست کننده و کاربر را دریابیم. فرض کنید کاربری با سطح امنیت سری موجود باشد واین کاربر همیشه به سیستم تحت عنوان درخواست کننده سری وارد شود. این درخواست کننده بر اساس قانون خواندن نمی تواند اطلاعات از نوع فوق سری را بخواند. قانون نوشتن دو نتیجه دارد که در نگاه اول ممکن است در تناقض با هم بنظر آیند: درخواست کننده سری می تواند یک منبع نوشتنی ایجاد کند(اگرچه قادر به خواندن آن نیست).در واقع این درخواست کننده می تواند بر روی منابع نوشته و آنها را تغییر داده و یا آنها را خراب کند. به همین دلیل بسیاری از سیستم ها اجازه نوشتن در سطوح بالا را به درخواست کننده های سطوح پایین نمی دهند و آنها تنها مجاز به نوشتن ، در منابع هم سطح با سطح خود می باشند که این نوشتن نیز دارای محدودیت هایی است. از طرفی این درخواست کننده های سطح سری می تواند به درخواست کننده های سطح فوق سری پیغام داده ، با آنها ارتباط برقرار کرده و درخواست های خود را به آنها ابلاغ کنند و از مزایای این کار بهره گیرد.
درخواست کننده سری ، نمی تواند بر روی داده های سطوح محرمانه و غیر محرمانه بنویسد ، به این معنی که این درخواست کننده نمی تواند هیچ پیغامی به کاربران سطح محرمانه و غیر محرمانه بدهد و این یک تناقض است و بصورتی که در زیر توضیح داده شده است حل می شود. به درخواست کننده سری اجازه داده می شود تا به سیستم تحت عنوان کاربر محرمانه و غیر محرمانه وصل شود و به کاربران سطح محرمانه و غیر محرمانه پیغام دهد. به عبارت دیگر کاربر می تواند به سیستم تحت عنوان کاربرانی که سطح امنیت پایین تری دارند وصل شود.
پس علت استفاده از قانون نوشتن چیست؟ دلیل اصلی این است که مانع نفوذ اطلاعات توسط نرم افزارها از سطوح بالایی امنیت به سطوح پایین و نتیجتا فاش شدن آنها شود. به کاربران اعتماد شده است تا اطلاعات را فاش نکنند ولی نرم افزارهای تحت فرمان آنها ممکن است مورد سوء استفاده قرار گیرند و شایستگی چنین اعتمادی را ندارند. به عنوان مثال کاربری با نام یاشار با سطحی به سیستم وصل می شود که قادر به خواندن اطلاعات نیست. در نتیجه ، نمی تواند اطلاعات را از سطح سری به سطوح پایین تر انتقال دهد. قانون نوشتن مانع انتقال تصادفی اطلاعات از سطوح بالا به پایین می شود.
سطح صحت46 می تواند سخت47(C) ، مهم48 (I)و مبهم49(U) باشد. سطح صحت مرتبط با یک منبع ، نشان دهنده درجه اطمینان به اطلاعات موجود در آن منبع و پتانسیل آسیب پذیری آن در صورت تغییر غیر مجاز اطلاعاتش است. سطح صحت مرتبط با کاربر ، نشان دهنده میزان اطمینان به کاربر در انجام عملیاتی نظیر درج، ذخیره ، حذف و یا تغییر داده ها و برنامه های آن سطح می باشد. قوانینی نظیر آنچه که درباره امنیت بیان شد ، در اینجا نیز مورد نیاز است تا یکپارچگی حفظ شود :
قانون خواندن : سطح صحت درخواست کننده باید از سطح صحت منبع قابل خواندن ، پایین تر باشد.
قانون نوشتن: سطح صحت درخواست کننده باید از سطح صحت منبع قابل نوشتن ، بالاتر باشد.
ارضا این دو قانون امنیت صحت را با مانع شدن از انتقال اطلاعات ذخیره شده در منابع سطح پایین به منابع سطح بالا تضمین می کند(شکل2-9).

شکل 2-9 : کنترل انتشار اطلاعات برای تامین صحت
کنترل انتقال اطلاعات یکی از روش های تامین صحت می باشد و به طور کلی تامین صحت نیازمند مکانیزم گسترده تری است. تفاوت شکل های 2-8 و 2-9 در جهت انتقال اطلاعات است. به عبارت دیگر در هر دو اطلاعات تنها در یک جهت منتقل می شود. ماهیت سیاست اجباری ، در یکطرفه بودن جهت انتقال اطلاعات در شبکه تامین امنیت است.

شکل 2-10 : کنترل دسترسی اجباری

شکل 2-11 : اعمال همزمان دو سیاست تشخیصی و اجباری در سیستم
دو سیاست اجباری و تشخیصی در انحصار متقابل با یکدیگر نیستند. آنها قابل ترکیبند به طوری که
سیاست اجباری برای کنترل تفویض اختیار و سیاست تشخیص برای کنترل دسترسی استفاده می شود. شکل 2-11 همکاری دو سیاست را نشان می دهد.

2-4-3-3-3 سیاست مبتنی بر نقش
سیاست تشخیص و اجباری که درباره آنها صحبت شد مباحث کلاسیک در مقوله امنیت می باشند. تحقیقات نشان می دهد که بسیاری از نیاز های که در عمل با آنها مواجه هستیم در این دو سیاست کلاسیک منظور نشده است. سیاست اجباری از محیط های نظامی برخاسته و سیاست تشخیص توسط محققین معرفی شده است. در هیچیک ، نیاز های محیط های تجاری در نظر گرفته نشده است. در نتیجه سیاست جایگزین به جای سیاست های کلاسیک گذشته ، برای رفع این نیاز ها ارائه شد. سیاست مبتنی بر نقش تفویض اختیار برای کاربر یا برای گروه کاربران بر روی منابع را مانند آنچه که در رویکرد تشخیص گفته شد ، ارائه می دهد و نیز مبانی امنیتی که در سیاست اجباری گفته شد را در اختیار قرار می دهد. این سیاست دسترسی کاربر به اطلاعات را بر مبنای فعالیتی که کاربر بر روی سیستم اجرا می کند، کنترل می کند و نیازمند شناسایی نقش ها50 بر روی سیستم می باشد. یک نقش بر اساس مجموعه اعمال و مسئولیت های مرتبط با فعالیت ها ، تعریف می شود. بجای مشخص نمودن تمامی دسترسی ها ، اجازه دسترسی به منابع در نقش ها گنجانده شده است . هر کاربر مجاز به اجرا است. به کاربران اجازه پذیرفتن نقش ها داده شده است. تحقیقات به عمل آمده این حقیقت را که نقش ها برای بسیاری از تاسیسات دولتی و تجاری مناسب هستند را ، اثبات می کند. کاربری که نقشی را ایفا می کند مجاز به اجرای تمام دسترسی هایی است که نقشش ایجاب می کند. عموما یک کاربر می تواند نقش های متفاوتی را بپذیرد و همچنین نقش های یکسان می تواند توسط افراد متفاوتی ایفا شوند. در بعضی از رویکرد ها یک کاربر می تواند در یک زمان نقش های متفاوتی ایفا کند و در بعضی دیگر کاربر ، تنها مجاز به ایفای یک نقش در آن واحد محدود می شود. به طور کلی استاندارد های متفاوتی وجود دارد و رویکرد های متفاوتی در این زمینه اعمال می شود. این سیاست چندین مزیت دارد که در ذیل مختصرا در مورد آن ها بحث شده است:
* مدیریت اختیارات : سیاست مبتنی بر نقش از یک استقلال منطقی51 در تعریف اختیارات کاربران برخوردار است. با تقسیم بندی عمل انتساب اختیار به دو بخش، که یکی از بخش ها کاربران را به نقش ها انتساب می دهد و بخش دیگر حق دسترسی منابع به نقش ها را معین می کند به این مهم دست می یابد. این کار به مقدار بسیار زیادی مدیریت امنیت را آسان می کند. به عنوان مثال فرض کنید مسئولیت های یکی از کاربران به علت ترفیع درجه تغییر کند. می توان نقش های گذشته را حذف و نقش های متناسب با مسئولیت های جدید را به وی انتساب داد. اگر تمامی اختیارات بین منابع و کاربر برقرار باشد باید تمام حقوق دسترسی قبلی کاربر حذف شده و حق دسترسی های جدید ایجاد شوند که این کار بسیار وقت گیر است.
* استفاده از سلسله مراتب : در بسیاری از سازمان ها نقش ها بصورت سلسله مراتبی ، بر اساس اصول و مشخصه های سازمان تعریف می شوند. یک مثال از این نمونه در شکل1-12 آورده شده است. در این شکل نقش های مهندسی نرم افزار و سخت افزار نمونه ای از نقش مهندسی هستند.کاربری که نقش مهندسی نرم افزار( یا سخت افزار) را دارد ، مزایا و اختیارات کلی و عمومی خود را از نقش مهندسی دریافت می کند. نقش ناظر نیز اختیارات و مزایای عمومی خود را از دو نقش مهندسی نرم افزار و سخت افزار دریافت می کند. نتیجتا تعریف نقش ها بصورت سلسله مراتبی باعث ساده شدن مدیریت اختیارات می شود.

شکل 2-12 : نمونه ای از ارث بری در نقش ها

* جداسازی وظیفه ها: جداسازی وظیفه ها به این اصل اشاره دارد که به هیچ کاربری نباید آنقدر اختیارات داده شود که بتواند از آنها به نفع خود سوءاستفاده کند. جداسازی وظیفه ها را می توان بصورت استاتیک(با تعریف نقش هایی که بوسیله کاربر قابل اجرا نیستند) و یا پویا(با اعمال کنترل بر روی دسترسی ها در زمان دسترسی) پیاده سازی کرد.
* کلاس بندی منابع: سیاست مبتنی بر نقش کاربران را بر اساس نقش هایی که اجرا می کنند کلاس بندی می کند. اعمال این کلاس بندی بر روی منابع مزایای بسیاری دارد.به عنوان مثال یک کارمند بانک باید به حساب های بانکی و یک منشی به نامه ها و یادداشت ها دسترسی داشته باشد. منابع باید بر حسب نوعشان( نامه ها ، دستورعمل ها و …) یا محدوده عملیاتی(نامه های تجاری ، تبلیغاتی و …)طبقه بندی شوند. تفویض اختیار به نقش ها باید بر اساس طبقه بندی منابع ، صورت گیرد نه بر اساس یک منبع خاص . به عنوان مثال همانطور که گفته شد منشی نیاز به دسترسی به نامه ها دارد. به جای دادن حق خواندن و نوشتن بر روی تک تک نامه ها این اختیارات به کل کلاس نامه ها داده می شود. با توجه به مطالب یاد شده این رویکرد مدیریت تفویض اختیار را آسان و کنترل آن را ساده می کند.
2-5 مدیریت تفویض اختیار
مدیریت تفویض اختیار به این معنی است که چه کسی مجاز به تغییر دسترسی هایی است که اعطا شده است. این مسئله یکی از مهم ترین مسائل کنترل دسترسی می باشد. در سیاست اجباری کنترل دسترسی ، دسترسی های مجاز ، بر اساس کلاس بندی منابع و درخواست کننده ها مشخص می شوند. سطوح امنیت، بوسیله مدیر امنیت به کاربر انتساب داده می شوند. مدیر امنیت در واقع تنها کسی است که می تواند سطوح امنیت مرتبط با درخواست کننده ها و منابع را تغییر دهد. بنابراین سیاست های مدیریتی ، بسیار ساده می شوند. سیاست تشخیص کنترل دسترسی اجازه فعالیت بسیاری از سیاست های مدیریتی را می دهد که در ذیل به بررسی چند نمونه از آن ها می پردازیم:
* مدیریت متمرکز: یک اختیار دهنده( یا گروه اختیار دهنده) مجاز به واگذاری اختیار به کاربر و یا لغو اختیار از وی می باشند.
* سلسله مراتب: در این سیستم ها یک اختیار دهنده مرکزی وجود دارد که وظیفه او تفویض مسئولیت های مدیریتی به دیگر مدیران است. این مدیران می توانند اختیارات سایر کاربران را تغییر دهند. در ضمن می توان مدیران را بر اساس چارت سازمان با مسئولیت های متفاوت طبقه بندی کرد.
* همکاری: اعطای یک اختیار خاص بر روی منابع نیاز به تایید و همکاری چندین مدیر را دارد.
* مالکیت: یک کاربر مالک منابعی است که خود ایجاد کرده است و می تواند به کاربران دیگر حق دسترسی اعطا کرده و یا حق دسترسی را سلب کند.
* مدیریت غیر متمرکز: در مدیریت غیر متمرکز مالک یک منبع می تواند امتیاز مدیریت تفویض اختیار بر روی آن منبع را به کاربران دیگر اعطا کند.
سیاست مبتنی بر نقش نیز همانند سیاست تشخیص ، طیف وسیعی از سیاست های مدیریتی را پشتیبانی می کند.در این راستا نقش ها سهم بسزای در امر مدیریت اختیار دارند.
2-6 جمع بندی
کنترل دسترسی به منظور رسیدن به اهداف امنیت و صحت ضروری است. رویکرد رایج برای پیاده سازی کنترل دسترسی لیست دسترسی می باشد.
سیاست های تشخیص و اجباری کنترل دسترسی مباحث کلاسیک در مقوله امنیت می باشند. تفاوت های این دو سیاست بسیار مفید است ولی این دو سیاست در عمل توانایی کمی دارند. سیاست مبتنی بر نقش یک جایگزین مناسب برای سیاسست خشک و غیر منعطف اجباری است مضاف اینکه انعطاف پذیری سیاست تشخیص را نیز دارد.
در پایان لازم بذکر است یکپارچه سازی امنیت کامپیوتر و شبکه(یا انتقال) برای دستیابی به اصول حقیقی در امنیت اطلاعات ، امری ضروری است. اگرچه تلاش های بسیاری در این زمینه شده ولی هنوز راه درازی باقیست.

فصل سوم بررسی امنیت در نرم افزار SQLServer2005

3-1 مقدمه
امنیت درSQL Server 2005 شامل هویت شناسی ، تفویض اختیار و رمزنگاری می باشد. تعیین اینکه چه افرادی به SQLServer دسترسی داشته باشند و هر یک از این افراد چه دسترسی هایی داشته باشند امری اساسی است. در ذیل به بررسی این مفاهیم در SQL Server 2005 می پردازیم.
3-2 هویت شناسی
هویت شناسی مهمترین مساله ای است که در فرایند نصب با آن مواجه هستیم و مهمترین تصمیمی که در مورد سرویس دهنده ( SQL Server ) باید گرفته شود تعیین مد هویت شناسی است. برای هویت شناسی دو انتخاب وجود دارد : مد هویت شناسی ویندوزی (WAM)52 و مد ترکیبی (MM)53 که به بررسی آنها می پردازیم.
3-2-1 مد هویت شناسی ویندوزی (WAM)
برای برقراری ارتباط ، با ویندوز های 2000/2003/XP -بر خلاف ویندوز های 9X و 98 که استفاده از ID در آن اختیاری است- باید ، از یک شناسه کاربری54 (ID) استفاده شود. قبل از اینکه کاربر قادر به داخل شدن به سیستم باشد ، باید ID و کلمه رمز55(PW) در ویندوز اعتبارسنجی56 شوند. در واقع با این عمل ، ویندوز اختیارات کاربر را می سنجد و همچنین گروهی را که کاربر به آن متعلق است(حق دسترسی) را تشخیص می دهد. کاربر ، ممکن است مدیر57 باشد. کاربری با این حق دسترسی ، قادر به انجام هر کاری می باشد. همانطور که در بخش های قبل توضیح داده شد ، هر چه در سطوح امنیت به سمت پایین حرکت کنیم دسترسی ها کمتر و اختیارات محدود تر می شود و این مبنای ایجاد یک ارتباط سالم است. برنامه هایی که پس از برقراری ارتباط با ویندوز شروع به کار می کنند ، به دلیل اینکه توسط ویندوز اعتبارسنجی شده اند و بررسی های امنیتی بر روی آن ها انجام شده است ، قابل اطمینان هستند . به همین دلیل هنگامی که ما وارد سیستم عامل ویندوز می شویم ، SQL Server از وجود یک ارتباط مطمئن58 بهره می برد و این به این معنی است که اعتبار سنجی یاد شده توسط ویندوز از نظر SQL Server قابل اعتماد است. فرض کنید کاربری به سیستم از طریق ویندوز راه پیدا کرده و سعی بر اجرایSQL Server داشته باشد. SQL Server به بررسی گروه ویندوزی که کاربر به آن متعلق است می پردازد و وضعیت امنیتی گروه را بررسی می کند تا دریابد آیا این گروه مجاز به دسترسی به SQL Server هست یا نه. اگر کاربری جزء گروه مدیر ، در ویندوز باشد قادر به ایجاد ارتباط با SQL Server است. این کاربر توانایی انجام هر فعالیتی را در مد یاد شده دارد. البته امکاناتی در داخلSQL Server وجود دارد که دسترسی مدیر ویندوز را نیز به SQL Server محدود می کند.
3-2-2 مد ترکیبی (MM)
اگر نصب SQL Server در مد ترکیبی باشد این به این معنی است که می توانیم به SQL Server با هویت شناسی بوسیله ویندوز و یا با هویت شناسی توسط SQL Server وصل شویم. در مورد هویت شناسی توسط ویندوز صحبت شد. حال به بررسی هویت شناسی توسط SQL Server می پردازیم. در هویت شناسی توسط SQL Server از یک Username و کلمه رمز که در SQL Server تعریف شده است برای هویت شناسی استفاده می شود. این Username هیچ ارتباطی با Username های موجود در ویندوز ندارد. با توجه به اینکه در هویت شناسی توسط ویندوز ، از مکانیزم امنیت موجود در سیستم عامل استفاده می شود ، هویت شناسی توسط ویندوز به هویت شناسی توسط SQL Server ارجحیت دارد. حال سوالی که به ذهن می رسد این است که تفاوت WAM با MM چیست؟ برای بیان این تفاوت ، به بررسی چند مثال می پردازیم. مد ترکیبی هنگام کار با ISP ها در بسیاری از موارد چاره ساز است. فرض کنید شما در حال کار با داده های دوردست59 موجود در یکی از کامپیوترهای شبکه محلی هستید- و این شبکه بصورت گروه کاری60 باشد. در این حالت در صورت استفاده از WAM ، باید برای هر کاربر موجود در شبکه ، در ویندوز کامپیوتری که داده ها را در دست دارد ID تعریف شود تا در این حالت این کاربران بتوانند با WAM به SQL Server متصل شوند. در صورت استفاده از MM ، ID هایی در SQL Server تعریف می شوند و هر کاربر بر اساس ID موجود در SQL Server شناسایی می شود. در پروژه های بزرگ ، گروه بزرگی از افراد شرکت دارند که تعدادی از آن ها بصورت موقتی در پروژه حضور دارند و پس از پایان کار خود ، پروژه را ترک خواهند کرد. در این حالت نیاز به تعریف ID های موقتی- بر خلاف ID های ثابت که در گروه های ویندوزی تعریف می شوند_ امری ضروری به نظر می رسد. می توانیم این کاربران را در SQL Server تعریف کنیم و از مزایای این کار بهره ببریم. این کاربران در SQL Server دارای حق دسترسی متفاوتی هستند.
حال به برنامه های مبتنی بر اینترنت61 توجه کنید که در آن تعریف یک ID برای هر کاربری که قصد بازدید از سایت را دارد تقریبا غیر ممکن است. در این حالت یک ID عمومی نیاز داریم که توسط ویندوز تعریف نشده باشد و هویت شناسی به عهده SQL Server باشد.
در مواردی که سیستم عامل موجود در سیستم ها چیزی غیر از سیستم عامل ویندوز است به ناچار از MM استفاده می شود.
در حالت کلی مواردی وجود دارند که یا در آنها استفاده از WAM غیر ممکن است و یا پیاده سازی آن در محیط دشواری های بسیاری دارد. در این مواقع هویت شناسی توسط SQL Server مناسب تر به نظر می رسد.
برای تغییر مد هویت شناسی ابتدا در Object Explorer بر روی سٍرور کلیک راست کرده و سپس Properties را انتخاب کنید(شکل3-1)

شکل 3-3 : Object Explorer
حال بر روی Security کلیک کنید. در پنجره باز شده می توان مد هویت شناسی را تغییر داد(شکل 3-3 )

شکل 3-3 : تغییر مد هویت شناسی
3-3 Logins
تنها راهی که افراد می توانند به SQL Server متصل شوند Login می باشد. همانطور که قبلا هم گفته شد دو نوع هویت شناسی وجود دارد. در هویت شناسی ویندوزی ، اگر کاربری متعلق به گروهی در ویندوز بوده و این گروه در SQL Server تعریف شده باشد ، این کاربر قابلیت دسترسی به SQL Server را دارد. وقتی یک پایگاه داده بوجود می آید ، بصورت پیش فرض فقط مالک پایگاه داده اختیار تام برای انجام هر عملی در پایگاه داده را دارد ، از جمله می توان ساخت جدول ، وارد کردن داده و یا مشاهده داده را نام برد. فقط هنگامی که مالک پایگاه داده به کاربران دیگر اختیار دهد ، کاربران قادر به انجام فعالیت هایی بر روی پایگاه داده می باشد. در مورد Login ها مسئله مهم دیگری وجود دارد و آن گروه بندی Login ها می باشد . Login ها را می توان بر اساس سیاست های مختلفی از جمله با توجه به اینکه به کدام بخش از سازمان مربوط هستند و یا بر اساس اختیاراتی که به گروه ها داده شده است ، گروه بندی کرد . فعالیت هایی را که این گروه ها انجام می دهند متفاوت است. در واقع گروه بندی نوعی تقسیم بندی وظایف است و کاربران با مسئولیت های یکسان در یک گروه قرار می گیرند.

3-3-1 Login های ویندوز و کاربران پایگاه داده
3-3-1-1 ایجاد گروه در ویندوز
برای ایجاد گروه ها در ویندوز به صورت زیر عمل می کنیم. لازم به ذکر است که ایجاد یک کاربر در ویندوز نیز به همین شکل است.
مسیر زیر را دنبال کنید:
Start Control Panel Administrative Tools Computer Management
در پنجره ای که ظاهر شده Local User and Group Group را انتخاب کنید. پس از انجام این کار تعدادی از گروه هایی را که از قبل در کامپیوتر شما بوده را مشاهده خواهید کرد. تعدادی از گروه های از پیش تعریف شده در SQL Server نیز وجود دارد. این گروه ها با گروه هایی که قرار است به اطلاعات دسترسی داشته باشند تفاوت دارند.

شکل 3-3 : لیست گروه های موجود در کامپیوتر
بر روی Group کلیک راست کرده و New Group را انتخاب کنید. حال می توانیم گروه جدیدی ایجاد کنیم.

شکل 3-4 : اضافه کردن گروه
با کلیک بر روی Add می توان کاربران ویندوز را به گروه خود اضافه کرد.

شکل 3-5 : Yashi آماده اضافه شدن به گروه
پس از پایان اعمال فوق ، گروه جدید ایجاد شده است.

شکل 3-6 : گروه جدید اضافه شده است
3-3-1-2 ارتباط گروه های ویندوز با کاربران SQLServer با استفاده از GUI
حال که گروه جدیدی را در ویندوز ایجاد کرده ایم ، می توانیم آن را به SQL Server اضافه کنیم. SQL Server Management Studio را باز کرده و از Object Explorer ، Security/Login را انتخاب کنید. سپس بر روی New Login کلیک کنید. شکل 3-7 در پیش روی شما خواهد بود. بر روی Search کلیک می کنیم تا بتوانیم گروه مورد نظر را انتخاب کنیم. برای اینکه عمل جستجو بر روی گروه ها انجام شود باید بر روی Object Types کلیک کرده و Groups را انتخاب کنیم.

شکل 3-7 : ایجاد یک Login جدید

شکل 3-8 : جستجو برای یافتن گروه ها
با کلیک بر روی Advance می توان عملیات جستجو را تکمیل کرد. گروه مورد نظر را همانند آنچه در شکل 3-9 نشان داده شده انتخاب کرده و OK کنید.

شکل 3-9 : یافتن گروه Group 1
در این مرحله همانطور که در شکل 3-10 نیز نشان داده شده ، گروه مورد نظر انتخاب شده است.

شکل 3-10 : گروه انتخاب شده آماده اضافه شدن است
اکنون زمان آن فرا رسیده تا به گروه انتخاب شده دسترسی های لازم به پایگاه داده مورد نظر اعطا شود. اعطای دسترسی باید در حد نیاز هر گروه و یا کاربر باشد و اعطای دسترسی ، بیش از حد مورد نیاز ، سیستم را از نظر امنیتی تضعیف می کند. در این قسمت ما به Group1 ، تنها اجازه دیدن پایگاه داده Pubs را می دهیم. توضیحات بیشتر در این مورد هنگام بررسی نقش ها داده خواهد شد. اگر در صفحه شکل 3-11 ، بر روی دکمه Script کلیک کنیم عبارات T-SQL به ما نشان داده خواهد شد.

شکل 3-11 : اعطای دسترسی به پایگاه داده به Login مورد نظر
عبارات T-SQL متناظر با اعمال انجام شده در فوق را مشاهده می کنید. در این باره در آینده توضیح بیشتری داده خواهد شد.
USE [master]
GO
CREATE LOGIN [YASHARGroup 1] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
USE [pubs]
CREATE USER [YASHARGroup 1] FOR LOGIN [YASHARGroup 1]
صفحه Status را انتخاب کنید.در اینجا قادر به اعطا و یا سلب دسترسی به SQL Server برای کاربران و گروه های موجود در ویندوز و Login های موجود در SQL Server هستیم.

شکل 3-12 : وضعیت Login
حال که گروه جدید ساخته شده و در SQL Server جای گرفته هر یک از اعضای این گروه می توانند به SQL Server متصل شده و به پایگاه داده Pubs دسترسی پیدا کنند. همانطور که قبلا هم متذکر شدیم ، این روند برای ایجاد یک کاربر تنها نیز یکسان است.
برای اینکه هویت شناسی توسط SQL Server انجام شود ، لازم است هر کاربر بصورت مجزا اضافه شود. روال کار همانند آنچه که در هویت شناسی توسط ویندوز توضیح داده شد می باشد ولی باید کلمه عبور مناسب انتخاب گردد.
3-3-1-3 ارتباط گروه های ویندوز با کاربران SQLServer با استفاده از کد های T-SQL
در بالا دیدیم که چگونه Login را بصورت گرافیکی درست می کنند. حال می خواهیم با استفاده از کد های T-SQL همین کار را انجام دهیم.
از SQL Server ، New Query را انتخاب کنید.
می خواهیم دومین گروه Login را بوجود آوریم. بر اساس اینکه هویت شناسی توسط ویندوز باشد یا SQL Server ، دو متد مختلف وجود دارد.در مثال بالا از متد ویندوزی استفاده شد.کد T-SQL تولید شده درشکل 3-11 مثال فوق برای راحتی ارجاع در ذیل آورده شده است.
USE [master]
GO
CREATE LOGIN [YASHARGroup 1] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
USE [pubs]
GO
CREATE USER [YASHARGroup 1] FOR LOGIN [YASHARGroup 1]
GO
حال با تغییر این کد می توان به یکی از گروه های موجود در ویندوز امکان مشاهده پایگاه داده Pubs را فراهم کرد. در این کد ، گروه مورد نظر بصورت پیش فرض به پایگاه داده Pubs متصل است. دستور CREATE LOGIN به SQL Server اطلاع می دهد که شما خواهان ایجاد یک Login جدید با نام Group 2 می باشید. در اینجا YASHAR نام دامنه شبکه62 ای است که Group 2 در آنجا یافت می شود. شما باید این نام را بر اساس دامنه مورد نظر تغییر دهید. کلمه کلیدی FROM WINDOWS به SQL Server اطلاع می دهد که شما در حال ایجاد یک Login با هویت شناسی توسط ویندوز هستید. کلمه کلیدی WITH DEFAULT_DATABASE یک ارتباط به پایگاه داده ایجاد می کند. البته باید نام پایگاه داده را مشخص کرد. در این مثال نام پایگاه داده Pubs است. در پایان DEFAULT_LANGUAGE ، زبانی را که در هنگام اتصال به پایگاه داده استفاده می شود را مشخص می کند.
CREATE LOGIN [YASHARGroup 2] FROM WINDOWS
WITH DEFAULT_DATABASE=[Pubs],
DEFAULT_LANGUAGE=[us_english]
پس از اجرای کد فوق Login جدید ایجاد می شود(شکل3-13).

شکل3-13 : Group 2 ایجاد شده است
امکان تغییر پایگاه داده ای که Login بصورت پیش فرض به آن وصل می شود وجود دارد. اگر به شکل3-7 مراجعه کنید متوجه می شوید که پایگاه داده پیش فرض متناظر با Group 1 ، master می باشد.بهتر است که یک Login فقط به پایگاه داده ای که به آن احتیاج دارد دسترسی داشته باشد. با استفاده از دستور Alter Login می توان پایگاه داده پیش فرض را تغییر داد.
ALTER LOGIN [YASHARGroup 1]
WITH DEFAULT_DATABASE=[Pubs]
قدم آخر ، اعطا63 دسترسی به کاربران ویندوز است تا Login ها بتوانند به پایگاه داده Pubs دسترسی پیدا کنند. برای این کار باید از پایگاه داده master به پایگاه داده Pubs سویچ کنیم. این عمل با استفاده از کلمه کلیدی USE انجام می شود.
دستور CREATE USER کاربری64 را که قرار است به پایگاه داده دسترسی داشته باشد را ایجاد می کند. کد زیر کاربری با نام Group 1 ایجاد کرده و Login مورد نظر را به آن می نگارد. در روش هویت شناسی توسط ویندوز بهتر است نام Login و گروه( کاربر) یکسان باشد.
USE Pubs
CREATE USER [YASHARGroup 2]
FOR LOGIN [YASHARGroup 2]

3-3-2 Login های سرویس دهنده65 و کاربران پایگاه داده
در SQL Server تفویض اختیار یک فرایند چند سطحی است که شامل تفویض اختیار در سطح سرویس دهنده و تفویض اختیار در سطح پایگاه داده می باشد. ایجاد Login ها و یا مدیریت سرویس دهنده مثال هایی از تفویض اختیار در سطح سرویس دهنده می باشند. خواندن داده ها از جداول و یا ایجاد جدول های جدید نیز مثال هایی از تفویض اختیار در سطح پایگاه داده می باشند. در واقع Login ها برای ایجاد ارتباط با SQL Server و انجام عملیاتی نظیر آنچه در مثال فوق ذکر شد بکار می روند و به داده ها دسترسی ندارند. این Login ها باید به کاربران66 ، که در سطح پایگاه داده تعریف می شوند نگاشته شوند تا بتوانند از مزایای آن ها ( کار با پایگاه داده) ، برخوردار شوند. یک Login می تواند به کاربران مختلف در پایگاه داده های مختلف نگاشت شود ولی امکان نگاشت یک Login به چند کاربر در سطح پایگاه داده وجود ندارد.
3-3-2-1 ایجاد Login در سطح سرویس دهنده با استفاده از GUI
ابتدا از Object Explorer ، Security/Login را انتخاب می کنیم. سپس بر روی New Login کلیک کنید. شکل3-14 در پیش روی شما خواهد بود. نامی برای Login مورد نظر خود انتخاب کنید(در این شکل SqlLogin1 به عنوان نام انتخاب شده است). بر روی SQL Server authentication کلیک کنید و کلمه رمزی برای Login خود انتخاب کنید.

شکل3-14 : ایجاد یک Login جدید
همانطور که گفته شد اختیارات Login ها در سطح سرویس دهنده می باشد و برای اینکه به پایگاه داده ها دسترسی داشته باشند باید به کاربران پایگاه داده نگاشته شوند. در شکل3-15 کاربری با عنوان dbUser1 ساخته شده و Login مورد نظر ما که همان SqlLogin1 است به آن متصل می شود. این کاربر به پایگاه داده Pubs دسترسی دارد و البته مالک آن نیز به شمار می رود.

شکل3-15 : اعطای دسترسی به پایگاه داده به Login مورد نظر
در مورد Securable و Server Roles در بخش های آینده بیش تر توضیح داده خواهد شد.
3-3-2-2 ایجاد Login در سطح سرویس دهنده با استفاده از کد T-SQL
برای انجام مراحل فوق از طریق کد T-SQL به صورت زیر عمل می کنیم :
USE [master]
CREATE LOGIN [SqlLogin2] WITH PASSWORD=N'plm789' DEFAULT_DATABASE=[pubs], DEFAULT_LANGUAGE=[us_english]
این کد یک Login با عنوان SqlLogin2 و با کلمه رمز plm789 می سازد. پایگاه داده پیش فرض pubs می باشد. زبان مورد استفاده us_english است.
3-3-3 Sa Login
Sa Login یک Login پیش فرض با اختیارات مدیریتی است. اگر کاربری با استفاده از این Login به SQL Server متصل شود ، بر تمامی جنبه های آن کنترل کامل خواهد داشت. SQL Server صرف نظر از اینکه در چه مد هویت شناسیی نصب شده است این ID را قبول می کند. اگر در ویندوز ، UserName با عنوان sa موجود باشد این کاربر قادر به وصل شدن به SQL Server می باشد ولی اختیاری بیش تر از این ندارد. توجه داشته باشید که Sa Login می تواند در گروه های دیگری غیر از گروه مدیر ویندوز ، تعریف شده باشد و به SQL Server متصل شود. به عبارت دیگر این Login صرف نظر از گروه ویندوزی که به آن متعلق است می تواند به SQL Server متصل شود. لازم به یادآوری است که می توان از ورود این کاربران به SQL Server جلوگیری کرد.
در هویت شناسی توسط SQL Server ، sa یک UserName معتبر خواهد بود. می توان حدس زد که کاربری با این UserName چه اختیاراتی دارد. او اختیار برای رویت ، تغییر و یا حذف هر داده ای دارد. در بدترین حالت این کاربر قادر به خراب کردن هر پایگاه داده ای است همانطورکه قادر به از کار انداختن خود SQL Server نیز هست. پس در حالت MM انتخاب کلمه رمز مناسب امری ضروری است به طوری که کسی قادر به حدس زدن آن نباشد و از انتخاب رمز های آسان برای این UserName پرهیز شود. دلایل دیگری نیز وجود دارد که به ما گوشزد میکند تا در استفاده از sa محتاط باشیم. ممکن است در مقطعی از زمان نیاز داشته باشیم تشخیص دهیم که چه کسی یک Query خاص را بر روی پایگاه داده اجرا کرده است و یا ممکن است کسی داده های زیادی را وارد پایگاه داده کرده و فضای زیادی از حافظه را مصرف کرده باشد و موجب بزرگتر شدن فایل log شده باشد. در این حالت باید با شخص مورد نظر تماس گرفته شود و او از ادامه این فرایند بازداشته شود. اگر این شخص با sa ، Login شده باشد هویت او قابل تشخیص نیست.
3-4 کنترل دسترسی(Access Control)
مالک منابع با استفاده از عبارات Grant ، Deny و Revoke دسترسی به منابع را کنترل می کند. اختیارات به Login های SQL Server ، گروه های ویندوز ، کاربران پایگاه داده ، نقش های پایگاه داده ای و نقش های برنامه ای بر روی منابعی نظیر Schema ، Type ، Assembly ، Table و … اعمال می شود. کلمات کلیدی توضیح داده شده است و مثال عملی در این باره در بخش های بعدی آورده شده است.
Grant : کاربر مجاز به انجام اختیار داده شده بر روی منبع مورد نظر می باشد. به عنوان مثال اگر اختیار Select بر روی جدول Table1 با کلمه کلیدی Grant مشخص شده باشد ، یعنی کاربر قادر به مشاهده داده های Table1 می باشد.
Deny : کاربر از انجام اختیار منع شده است. مثلا اگر اختیار Insert بر روی Table1 با کلمه کلیدی Deny مشخص شده باشد کاربر مجاز به وارد کردن داده های جدید در این جدول نمی باشد.
Revoke : Grant و Deny داده شده را لغو می کند.
برای آشکار شدن موضوع به بررسی چند مثال می پردازیم :
ابتدا پنجره new query را باز کنید. فرض کنید در پایگاه داده mydb کاربری به نام yashar و جدولی به نام mytbl وجود دارد. برای اعطا و یا سلب اختیار از این کاربر بصورت زیر عمل می کنیم :
USE mydb
اعطای امتیاز select به کاربر yashar در جدول mytbl
GRANT SELECT ON mytbl to yashar
اعطای امتیاز insert به کاربر yashar در جدول mytbl
GRANT INSERT ON mytbl to yashar
سلب امتیاز alter از کاربر yashar در جدول mytbl
DENY ALTER ON mytbl to yashar
اگر قبلا با دستور GRANT امتیازی مانند CONTROL به کاربر yashar اعطا شده باشد و یا با استفاده از دستور DENY امتیازی از وی سلب شده باشد ، با استفاده از دستور REVOKE هر یک از دستور های پیشین لغو می شود.
REVOKE CONTROL ON mytbl to yashar

3-5 نقش ها
در داخل SQL Server انواع مختلفی از نقش ها وجود دارد : نقش های ثابت سرویس دهنده67(FSR) ، نقش های پایگاه داده ای68 (DBR)، نقش های برنامه ای69(APR) که در ذیل به بررسی هر یک می پردازیم.
3-5-1 نقش های ثابت سرویس دهنده (FSR)
در داخل SQL Server تعدادی نقش از پیش تعریف شده وجود دارد که وظیفه آن ها محدود کردن فعالیتهای70 دیگر و یا اجازه شروع به بعضی از فعالیت ها می باشد. فردی با اختیار نوشتن مثلا مدیر سیستم71 می تواند این نقش ها را به هر کاربر و یا گروهی در داخل SQL Server انتساب دهد.اگر در Object Browser ، Server Role را مشاهده کنید ، لیستی از این نقش ها را خواهید دید(شکل 3-16).

شکل 3-16 : FSR
لازم بذکر است که امکان تعریف FSR جدید وجودندارد. نقش ها و وظایف آنها در ذیل آمده است:
bulkadmin : Insert های حجیم ، توسط این نقش انجام می شود.
dbcreator : وظیفه ساخت72 ، تغییر73 ، حذف74 پایگاه داده را دارد. در ضمن توانایی ذخیره کردن75 آنها را نیز دارد.
diskadmin : وظیفه مدیریت فایل های دیسکی را دارد.
securityadmin : وظیفه این نقش مدیریت Login ها است. اعضای این گروه می توانند اختیارات موجود در سطح سرویس دهنده و یا پایگاه داده را اعطا76 و یا ملغی77 کنند. تعیین کلمه رمز برای Login های SQL Server از جمله وظایف این نقش می باشد.
sysadmin : هر فعالیتی را می تواند انجام دهد.
serveradmin : وظیفه مدیریت SQL Server و انجام فعالیت های نظیر تغییر گزینه ها 78 و همچنین فعال کردن SQL Server برای انجام کارها و نیز غیر فعال کردن آن می باشد.
نقش های سرویس دهنده ، نقش های استاتیک هستند.حوزه فعالیت این نقش ها در سطح سرویس دهنده است.هنگام ایجاد Login ها در صورت نیاز می توان هر یک از این نقش های سرویس دهنده را به آن ها نسبت داد. در این صورت این Login ها علاوه بر مسئولیت هایی که در سطح پایگاه داده دارند ، می توانند به انجام فعالیت هایی در سطح سرویس دهنده نیز بپردازند.
اگر کاربر موجود در سطح ویندوز ، عضو گروه BUILTIN/Administrator باشد به صورت خودکار نقش sysadmin را در سطح سرویس دهنده خواهد داشت. با کلیک راست کردن بر روی sysadmin موجود در Server role و انتخاب Properties می توان این مطلب را بررسی کرد(شکل 3-17). توجه شود که BUILTIN/Administrator درلیست موجود در شکل3-17 وجود دارد. Login های دیگر می توانند با استفاده از دکمه Add به لیست اضافه شوند.

شکل3-17 : اعضای نقش sysadmin

3-5-2 نقش های پایگاه داده ای (DBR)
DBR با فعالیت هایی در ارتباط است که در سطح پایگاه داده انجام می پذیرند. نقش های موجود در SQL Server بر اساس نوع به چند بخش متفاوت تقسیم بندی می شوند. تعدادی از DBR ها همراه با نصب SQL Server ایجاد می شوند :
dbo/db_owner : مشخص کننده مالک پایگاه داده است.
db_accessadmin : مدیریت دسترسی Login ها به پایگاه داده بر عهده این نقش می باشد.
db_backupoperator : قابلیت پشتیبان گیری79 از پایگاه داده را دارد.
db_datareader : توانایی خواندن اطلاعات از جدول های تعریف شده توسط کاربر80 را دارد.
db_datawriter : توانایی نوشتن اطلاعات در جدول های تعریف شده توسط کاربر را دارد
db_ddladmin : اعضای این گروه توانایی اجرای دستورات از نوع DDL 81 را دارند. به عنوان مثال می توانند جدول بسازند.
db_denydatareader : اعضای این گروه نمی توانند هیچ داده ای را از جدول های تعریف شده توسط کاربر بخوانند.
db_danydatawriter : اعضای این گروه توانایی تغییر ، حذف ، و اضافه هیچ داده ای را در جدول های تعریف شده توسط کاربر ندارند.
db_securityadmin : اعضای این گروه توانایی تغییر عضویتِ در نقش ها را دارند.همچنینن وظیفه مدیریت اختیارات را بر عهده دارند.
public : هر کاربری که ایجاد می شود به این گروه متعلق است. این گروه می تواند به منابع عمومی82 دسترسی داشته باشد.
اگرچه می توان از نقش های از پیش تعریف شده پایگاه داده ای استفاده کرد ولی در بعضی مواقع ایجاد نقش های جدید مفید به نظر می رسد. این قابلیت در SQL Server تعبیه شده است. پس از ایجاد یک نقش جدید میتوان کاربران ویندوز ، گروه های ویندوز و یا Login های SQL Server را به نقش ها نسبت داد. برای انجام این کار بصورت زیر عمل می کنیم :
مسیر زیر را دنبال کنید :
Object Explorer Security User New User را انتخاب کنید(شکل 3-18)

شکل 3-18 : ایجاد کاربر در سطح پایگاه داده
در صفحه ظاهر شده(شکل 3-19) نامی را برای کاربر خود در نظر می گیریم. این کاربر باید با یک Login در ارتباط باشد.

شکل 3-19 : انتخاب نام برای کاربر پایگاه داده
در این قسمت Login مورد نظر خود را انتخاب کنید. همانطور که در شکل 3-20 نیز مشخص است اینLogin می تواند یکی از Login های SQLServer ، گروه و یا کاربر ویندوز باشد.

شکل 3-20 : انتخاب Login
پس از انجام مراحل فوق شکل 3-21 نمایان خواهد شد.

شکل 3-21 : Login انتخاب شده است
بر روی Securable در بالای صفحه کلیک کنید. برای اینکه کنترل دسترسی را بر روی منابع اعمال شود بر روی دکمه Add کلیک کنید.

شکل 3-22 :کلیک بر روی securable
حال منابعی را که می خواهید دسترسی به آن ها محدود شود را انتخاب کنید. در اینجا پایگاه داده و جدول ها برای این امر در نظر گرفته شده اند.

شکل 3-22 : انتخاب منابع برای اعمال محدودیت بر روی آنها
به طور مثال همانطور که در شکل 3-23 نیز مشخص است ، برای کاربر dbUser1 امکان تعریف جدول اعطا شده و امکان تعریف View تحریم شده است.

شکل 3-23 : تعریف دسترسی ها برای پایگاه داده Pubs
کاربر dbUser1 امکان Select و Update جدول Sales را دارد و امکان Take Ownership از وی سلب شده است(شکل 3-24).

شکل 3-24 : تعریف دسترسی ها برای جدول Sales
نکته قابل توجه این است که امکان محدود کردن Select نیز وجود دارد. اگر بر روی Select کلیک کنید دکمه Column Permission فعال می شود. پس از کلیک بر روی این دکمه می توان بر روی فیلد های این جدول اعمال محدودیت کرد. در شکل 3-25 این کاربر به فیلد های ord_date , ord_num , payments دسترسی داشته و اطلاعات موجود در فیلد های qty , stor_id , title_id از دید او پنهان است.

شکل 3-25 : اعمال محدودیت بر روی فیلد ها
3-5-3 نقش های برنامه ای (APR)
پایگاه داده ها برای استفاده برنامه ها به وجود می آیند. APR اجازه تعریف یک نقش برای دسترسی به پایگاه داده را می دهد. این نقش بر اساس برنامه ای که می خواهد به پایگاه داده وصل شود تعریف می شود. APR ها برای محدود کردن دسترسی برنامه ها به SQL Server تعریف می شوند. این نقش هیچ کاربری ندارد. از این نقش هنگامی استفاده می شود که می خواهیم تعیین کنیم یک برنامه به چه داده هایی دسترسی دارد و به چه داده هایی دسترسی ندارد. APR در هر دو مد هویت شناسی قابل استفاده است و بصورت پیش فرض غیر فعال است. این نقش با استفاده از رویه ذخیره شده83 sp_setapprole – که در پایگاه داده master قرار دارد- فعال می شود و به یک کلمه عبور نیاز دارد.
برای ایجاد یک APR مراحل زیر را انجام می دهیم :
1. از پایگاه داده Pubs ، Security را انتخاب کنید. بر روی Role کلیک راست کرده و New Application Role را انتخاب کنید. همانطور که در شکل3-26 نیز نشان داده شده ، نام و کلمه عبور مناسب برای نقش مورد نظر انتخاب کنید.

شکل3-26 : ایجاد APR
2. بر روی Securable کلیک کرده و دکمه Add را فشار دهید و مطابق شکل3-27 عمل کنید.

شکل3-27 : انتخاب نوع منبع
در این مرحله می توان به برنامه ، حق دسترسی به پایگاه داده و منابع دیگر را مشخص کرد.

شکل3-28: انتخاب پایگاه داده
مطابق شکل 3-28 عمل کرده و OK کنید. در واقع در مرحله قبل منابع مورد نظر را انتخاب کرده و در این مرحله اختیارات را مشخص می کنیم. همانطور که در شکل نیز مشخص است حق Insert ، Select و Delete در پایگاه داده اعطا شده است.

شکل3-29 : تنظیم کردن حقوق دسترسی
می توان با کلیک بر روی دکمه ColumnPermission کاربر را در مشاهده ستون های جدول محدود کرد.

شکل 3-30 : اعمال محدودیت در مشاهده فیلد ها
با این کاربر اجازه مشاهده ستون fname داده شده و این کاربر از مشاهده داده های ستون lname محروم است.

3-6 شِما84
شِما یک مجموعه ای از موجودیت های پایگاه داده ای است که یک فضانام85 را می سازد. یک فضانام مجموعه ای است که در آن هر عضو دارای یک نام منحصر بفرد است. به عنوان مثال ، برای جلوگیری از تداخل نام ها ، هیچ دو جدولی همنامی نمی تواند در یک شِما وجود داشته باشد. دو جدول تنها در صورتی می توانند همنام باشند که در دو شِمای متفاوت قرار داشته باشند. هر یک از منابع در پروژه به عنوان یک بخش کوچک از کل منابع موجود در یک پروژه می باشند. گروه بندی منابع کوچک موجب سازماندهی بهتر منابع و افزایش کارایی در استفاده از آن ها می شود و مبنایی برای ایجاد امنیت هنگام دسترسی به داده های موجود در SQL Server است.. بنابراین یک شما متدی برای گروه بندی منابع و قرار دادن منابع مورد نظر در آن شما است.
اگرچه در SQLServe2000 دستور CREATE SCHEMA وجود داشت ، ولی این دستور شمایی همانند آنچه که در بالا توضیح داده شد ایجاد نمی کرد. کاربران پایگاه داده و شما ها به طور غیر مستقیم با هم در ارتباط بودند. کاربران پایگاه داده ای که نام آنها همنام با نام شما بود مالک آن شما بودند و مالک یک منبع مالک شمایی است که آن منبع در آن قرار دارد. در نتیجه یک شما در SQL Server2000 یک کاربر در پایگاه داده نیز بود. در نتیجه قبل از حذف یک کاربر از SQLServer2000 ، باید تمامی منابع تحت مالکیت وِی حذف شده و یا مالکیت این منابع به کاربر دیگری واگذار می شد. فرض کنید منبع accounting.ap.george.reconciliation در پایگاه داده ای در SQL Server2000 وجود داشته باشد. این منبع تحت مالکیت george است. اگر مدیر بخواهد این کاربر را حذف کند باید ابتدا این منبع را حذف کند و یا مالکیت آن به شخص دیگری داده شود(مثلا به Sandra واگذار شود : accounting.ap.sandra.reconciliation). تغییر نام مالک ، نام کلی این منبع را نیز تغییر می دهد و هر کدی که با این منبع سروکار دارد باید این تغییر نام در آن کد نیز اعمال شود.
در SQLSever2005 ، شما مستقل از کاربر پایگاه داده ایست که آن را ایجاد کرده است.تعویض مالکیت شما بدون تغییر نام آن صورت می گیرد. به عنوان مثال به جای ساختن شما با نام accounting.ap.sandra.reconciliation می توان شمایی با نام accounting.ap.invoice.reconciliation ساخت که invoice در آن نام یک کاربرنیست. با انجام این عمل کار مدیر پایگاه داده آسان تر می شود.
در SQL Server منابع برای نگه داری داده های استفاده می شوند و کار با داده ها را آسان می کنند. هر یک از این منابع به عنوان یک بخش کوچک از کل منابع موجود در یک پروژه می باشند. گروه بندی منابع کوچک موجب سازماندهی بهتر منابع و افزایش کارایی است و مبنایی برای ایجاد امنیت هنگام دسترسی به داده های موجود در SQL Server می باشد. این گروه بندی در SQL Server تحت عنوان SCHEMA مطرح است. بنابراین یک SCHEMA متدی برای گروه بندی منابع است. قبل از SQL Server2005 هر منبع یک مالک داشت.هنگامی که مالکی(کاربری) پروژه را ترک می کرد ، مالکیت منابع تحت اختیار او باید به شخص دیگری منتقل میشد و مسلّم است در یک سیستم بزرگ این انتقال مالکیت ، زمانبر است. حال SCHEMA ها مالکیت منابع را بر عهده دارند.
3-7 Principal
Principal ممکن است یک فرد ، یک گروه و یا فرایند هایی باشند که برای دسترسی به منابع SQL Server درخواست می دهند. Login های ویندوزی مثالی از افراد و گروه های ویندوزی مثالی از گروه هایی هستند که ممکن است برای دسترسی به منابع SQL Server اقدام کنند. حوزه تاثیرگذاری principal ها به حوزه تعریف86 آن ها بستگی دارد. منظور از حوزه تعریف یعنی اینکه principal ها در کدام یک از سطوح ویندوز ، سرویس دهنده یا پایگاه داده تعریف شده اند و نیز بصورت فردی تعریف شده اند یا گروهی. هر principal یک 87SID منحصر بفرد دارد. انواع principal ها و حوزه عملیاتی آن ها در جدول زیر توضیح داده شده است :
جدول 3-1 : انواع principal و حوزه عملیاتی آنها
Principal
حوزه عملیاتی
توضیحات
Windows Login
سرویس دهنده
Login های ویندوز در کامپیوتر محلی و در دامنه شبکه تعریف می شوند. مدیریت این درخواست دهنده ها خارج از دسترس SQL Server است.
SQL Server Login
سرویس دهنده
این Login ها در داخل یکی از نمونه های SQL Server تعریف می شوند و در خارج از این محدوده کاربردی ندارند.
User
پایگاه داده
کاربران پایگاه داده برای دسترسی به پایگاه داده تعریف می شوند و یک Login ، متناظر با هر کاربر پایگاه داده وجود دارد. و هر Login به یک کاربر پایگاه داده نگاشت می شوند. این کاربران خارج از محدوده پایگاه داده غیر قابل استفاده هستند.
Application Role
پایگاه داده
نقش های برنامه ای در سطح پایگاه داده قابل استفاده هستند ولی با هیچ Login ی ارتباط ندارند. محدود به پایگاه داده هستند و با یک نام و کلمه عبور شناسایی می شوند.
Database Role
پایگاه داده
نقش های پایگاه داده ای در سطح پایگاه داده تعریف می شوند.

توجه داشته باشید که Loginهای ویندوز و SQL Server فقط در سطح سرویس دهنده کاربرد دارند و نمی توانند به منابع پایگاه داده دسترسی داشته باشند. تنها در صورتی این امر امکان پذیر است که این Login ها به کاربرانی در سطح پایگاه داده نگاشته شوند.
3-8 Securable
Securable منابع در سطح پایگاه داده هستند که دسترسی Principal ها بر روی آن ها آن ها کنترل می شود. SQL Server توانایی شناسایی سه حوزه مختلف از منابع را دارد. در ذیل این سه حوزه و اجزای آن ها معرفی شده اند. پرداختن به جزئیات در این باره خارج از حوصله این بحث است.
Server scope securable :
Endpoint
Login
Database
Database scope securable:
User
Role
Application role
Assembly
Message Type
Route
Service
Schema
Remote service binding
Fulltext catalog
Asymmetric Key
Symmetric Key
Contract
Schema
Schema scope securable:
Type
XML Schema Collection
Object
3-9 Permission
Permission مکانیزم هایی هستند که از طریق آن ها مالک یک منبع به کاربران ذینفع قابلیت اجرای یکسری اعمال را بر روی آن منبع را می دهد.در واقع permission ها مشخص کننده مجموعه اعمالی است که یک کاربر می تواند در داخل SQL Server انجام دهد. در جدول زیر مجموعه ای از Permission های رایج آورده شده است.

جدول3-2 : انواع Permission
Principal
حوزه عملیاتی
توضیحات
Alter
اجازه ایجاد ، تغییر و از بین بردن منابع را می دهد.
Application Role
Assembly
Certificate
Login
Procedures (T-SQL and .NET)
Role
Schema
Symmetric Key
Tables
Views
Scalar and Aggregate Functions
(T-SQL and .NET)
User
XML Schema Collection
Control
دارنده این اختیار به نمایندگی از مالک می تواند هرگونه اختیاری را به کاربران دیگر اعطا کند و اجازه انجام هر عملی را دارد اگرچه شما مالک نباشد.
Application Role
Symmetric Key
Tables
Views
Scalar and Aggregate Functions
(T-SQL and .NET)
Synonyms
Table-Valued Functions
(T-SQL and .NET)
Type
User
XML Schema Collection
Delete

دارنده این اختیار اجازه حذف داده را دارد.
Schema
Synonyms
Tables and columns
Views and column
Execute
اجازه اجرای کد را میدهد. توابع88 و رویه های ذخیره شده89 از این جمله هستند.
Assembly
Scalar and Aggregate Functions
(T-SQL and .NET)
Schema
Synonyms
Type
XML Schema Collection
Impersonate
به شما اجازه می دهد تا خود را جای کاربر دیگری جا بزنید. بری انجام این کار نیازی نیست که شما sysadmin و یا DBO باشید.
Login
User

Insert
اجازه وارد کردن داده های جدید را به شما می دهد.
Schema
Synonyms
Tables and columns
Views and columns
Select
اجازه مشاهده داده ها را به شما می دهد.
Schema
Synonyms
Tables and columns
Table-Valued Functions (T-SQL
and .NET) and columns
Take Ownership
به شما اجازه می دهد تا مالکیت منبع مورد نظر را در اختیار بگیرید حتی اگر واگذار کننده این اختیار به شما DBO یا sysadmin نباشد.
Assembly
Certificate
Procedures (T-SQL and .NET)
Role
Tables.
Views
Scalar and Aggregate Functions
(T-SQL and .NET)
Schema
Symmetric Key
Synonyms
Table-Valued Functions
(T-SQL and .NET)
Type
XML Schema Collection

Update
اجازه تغییر داده را می دهد.
Schema
Synonyms
Tables and columns
Views and columns
View Definition
اجازه مشاهده ساختار جدول(metadata) را به شما می دهدحتی اگر شما اختیار دیگری بر روی آن جدول نداشته باشید. این یک اختیار جدید در SQL Server 2005 است.
Application Role
Login
Procedures (T-SQL and .NET)
Role
Schema
Symmetric Key
Synonyms
Tables
Type
Views
Scalar and Aggregate Functions
(T-SQL and .NET)
Table-Valued Functions
(T-SQL and .NET)
User
XML Schema Collection

حال به برسی چند مثال در این زمینه می پردازیم. اختیار Select بر روی جدول به شما اجازه می دهد تا داده ها ی موجود در جدول را مشاهده کنید ولی شما نمی توانید هر یک از اعمال insert ، Delete و یا Update را انجام دهید. انجام این اعمال در صورتی امکان پذیر است که اختیار آن به شما داده شده باشد. برای اضافه کردن یک ستون جدید در جدول از اختیار Alter و برای اجرای رویه های ذخیره شده و توابع از Execute استفاده می شود. اگر کاربری نیاز به مالکیت منبعی داشته باشد با Take Ownership و توسط DBO این عمل انجام می شود. نکته مهم در مورد اختیارات این است که اعطا کننده این اختیارات باید در انجام این عمل نهایت دقت را داشته باشد تا امکان سوءاستفاده از آن ها به حداقل برسد.
3-10 رمز نگاری90
یکی از اصلی ترین امکاناتی که برای بالا بردن امنیت در SQL Server 2005 گنجانده شده است ، رمز نگاری است. در این امکان ، داده ها با استفاده از عبارات T-SQL رمز نگاریی می شوند و در صورت نیاز رمزگشایی91 شده و استفاده می شوند. بهتر است قبل از ذخیره کردن داده های حساس-مثلا کلمه عبور کارت های اعتباری- در پایگاه داده ، این داده ها بصورت رمز درآورده شوند تا در صورت فروپاشی سیستم امنیت پایگاه داده ، این داده های حساس ، امن باقی بمانند.
SQL Server 2005 چهار جفت از توابع رمز نگار/رمزگشا را ارائه می دهد که هر جفت یک تکنیک خاص برای رمزنگاری را ارائه می دهد.
رمزنگاری کلمه عبور92(PE) : این شیوه ساده ترین و در عین حال ضعیف ترین شیوه رمزنگاری است. داده ها با یک رشته کلمه رمز تعیین شده توسط کاربر رمزنگاری می شود و قدرت کلمه عبور انتخاب شده بررسی نمی شود.
رمزنگاری کلید نامتقارن93 (AKE) : این شیوه قدرتمند ترین نوع رمزنگاری است چرا که از کلید های متفاوتی برای انجام عمل رمزنگاری و رمزگشایی استفاده می کند. نقطه ضعف این شیوه ، سرعت پایین آن است و در جایی که مقادیر عظیمی از داده وجود دارد کارا نیست. تنها در مواردی که مهمترین موضوع در رابطه با داده ها امنیت باشد و کارایی اهمیت کمتری داشته باشد از این شیوه استفاده می کنند. مثلا وزارت امنیت ایالات متحده برای امن کردن داده های خود از این شیوه استفاده می کند.
رمزنگاری کلید متقارن94(SKE) : در این شیوه از یک کلید واحد برای رمزنگاری و رمزگشایی استفاده می شود. SQL Server 2005 توسط دو دسته از توابع این عمل را انجام می دهد. که در دسته اول کلمه رمزی توسط کاربر ارائه می شود و در دسته دوم کلمه رمز به عنوان یک منبع در SQL Server ذخیره شده است.
رمزنگاری گواهینامه95 (CE) : گواهینامه ها برای اثبات درستی هویت نویسنده یک کد و یا فرستنده یک داده استفاده می شود.
3-10-1 رمزنگاری با استفاده از کلمه عبور کاربر
این روش هنگامی کارا است که کلمه عبور در سیستم ذخیره نشده ولی یک رشته شناخته شده برای کاربر است. از آنجا که کلمه عبور در سیستم ذخیره نشده است دیگر نگران ذخیره آن در یک مکان امن در سیستم نیستیم و این یکی از مزایای این روش است. برای رمزنگاری با استفاده از این روش از تابع EncryptByPassPhrase() استفاده می شود که مقداری را که باید رمزنگاری شود و عبارت عبور را به عنوان پارامتر می پذیرد. برای رمزگشایی از تابع DecryptByPassPhrase() عبارت عبور و رمز را به عنوان پارامتر می پذیرد.
با مثالی به ادامه بحث می پردازیم. فرض کنید در پایگاه داده university جدولی با عنوان tblStudent وجود دارد.

شکل3-31 : مقادیر جدول tblStudent قبل از رمز نگاری
با استفاده از تابع EncryptByPassPhrase() عمل رمز نگاری را انجام می دهیم :
UPDATE tblStudent
SET sname = EncryptByPassPhrase('password', sname)

شکل 3-32 : مقادیر جدول tblStudent پس از رمزنگاری
مشاهده می شود که پس از رمزنگاری داده ها غیر قابل استفاده می شود و اگر کسی تا این مرحله پیش رفته باشد و به جداول دسترسی داشته باشد از رویت داده های حساس باز می ماند. برای مشاهده داده ها باید آنها را رمزگشایی کرد :
SELECT sname as "Encrypted" ,CONVERT(varchar(50),DecryptByPassphrase('password', sname)) AS "Decrypted"
FROM tblStudent
نتیجه این انتخاب را در شکل2-32 مشاهده کنید.تابع CONVERT را به نوع دیگر تبدیل می کند. در اینجا این تابع عبارت رمزگشایی شده را به نوع varchar(50) تبدیل می کند. عملکرد این تابع همانند تابع CAST است.

شکل 3-33 : داده های رمزگشایی شده
3-10-2 رمزنگاری کلید متقارن
بعد از روش قبل ، راحترین و ساده ترین متد برای رمزنگاری داده ها استفاده از کلید متقارن ذخیره شده در پایگاه داده است. برای انجام هر دو عمل رمزنگاری و رمزگشایی از یک کلید متقارن استفاده می شود. برای ایجاد یک کلید متقارن در پایگاه داده از دستور create symmetric key استفاده می شود.
CREATE SYMMETRIC KEY key1
WITH ALGORITHM = TRIPLE_DES
ENCRYPTION BY PASSWORD = 'password'
الگوریتم های موجود برای رمزنگاری کلید متقارن DES ، TRIPLE_DES ، RC2 ، RC4 ، DESX ، AES128 ، AES192 و AES256 هستند.
برای رمزنگاری و یا رمزگشایی داده ها با استفاده از کلید متقارن ابتدا باید آنرا با استفاده از دستور OPEN SYMMETRIC KEY باز کنیم. تابع EncryptKeyBy() ،با استفاده از GUID 96 کلید رمزگذاری را انجام می دهد. این id با استفاده از تابع Key_GUID() بدست می آید.

OPEN SYMMETRIC KEY key1 DECRYPTION BY PASSWORD = 'password'
UPDATE tblStudent
SET city = EncryptByKey(Key_GUID('key1'), city)

پس از اجرای عبارات فوق ستون city از جدول tblStudent به صورت رمز نوشته می شود. برای رمزگشایی از دستورات زیر استفاده می کنیم :
SELECT
CONVERT(varchar(50), DecryptByKey(city))
AS 'city'
FROM tblStudent
3-10-3 رمزنگاری کلید نامتقارن
در رمزنگاری به شیوه کلید نامتقارن از دو کلید استفاده می شود : اولی یک کلید خصوصی است که بصورت محلی ذخیره شده و نباید فاش شود و دومی یک کلید عمومی است که در اختیار همگان قرار دارد. داده رمزنگاری شده توسط کلید عمومی فقط توسط کلید عمومی متناظر با خود قابل رویت است و برعکس. به عنوان مثال فرض کنید برای ارسال نامه های فوقِ سری به یک شخص بسیار مهم ، به هر فرد موجود در جامعه یک صندوق به همراه یک قفل داده شده است. تمامی این قفل ها یکسانند(کلید عمومی). افراد پس از قرار دادن نامه ها در صندوق ، آن ها را به شخص مهم تحویل می دهند. کلید این قفل های یکسان تنها در اختیار این شخص قرار دارد و تنها اوست که می تواند نامه ها را مشاهده کند(کلید خصوصی).
در این روش به دلیل اینکه کلید خصوصی نباید در شبکه منتقل شود ، مشکلات روش کلید متقارن پیش نمی آید.
به دلیل اینکه کلید عمومی در اختیار همه است ، هویت افرادی که داده ها را رمزنگاری کرده اند قابل تشخیص نیست. برای ایجاد یک ارتباط مطمئن از دو دسته کلید استفاده می شود :پیغام را با کلید خصوصی خودمان-که مشخص کننده هویت ما است- رمزنگاری می کنیم. سپس پیغام رمزی را با استفاده از کلید عمومی دریافت کننده پیغام ، دوباره رمزنگاری می کنیم. دریافت کننده می تواند با استفاده از کلید خصوصی خود و کلید عمومی ما پیغام را رمزگشایی کند.
با استفاده از این شیوه امنیت به بالاترین حد خود می رسد ولی متاسفانه از لحاظ قدرت اجرا بسیار ضعیف است. پس هنگامی که با مقادیر عظیمی از داده ها سرو کار داریم این شیوه ناکارامد است.
با استفاده از دستور CREATE SYMMETRIC KEY می توان یک کلید ناتقارن ساخت که این کار خود به دو صورت انجام می پذیرد :
ایجاد کلید نامتقارن با استفاده از الگوریتم :
عبارت ENCRYPTION BY PASSWORD مشخص کننده کلمه رمزی است که با آن کلید خصوصی رمزنگاری شده است. الگوریتم های قابل استفاده در این روش RSA_512 ، RSA_1024 و RSA_2048 می باشند.

CREATE ASYMMETRIC KEY key1
WITH ALGORITHM = RSA_512
ENCRYPTION BY PASSWORD = 'pass'

ایجاد کلید متقارن با استفاده از فایل : می توان با استفاده از یک فایل که با استفاده از دستور sn.exe ایجاد می شود استفاده کرد.
CREATE ASYMMETRIC KEY key1
FROM FILE = 'C:ApressSqlServer2005SecurityChapterEncryptionkeyfile.key'
ENCRYPTION BY PASSWORD = 'pass'
هر دو تابع EncryptByAsymKey() و DecryptByAsymKey() ، GUID کلید و عبارت رمزنگاری/رمزگشایی شده و کلمه عبور استفاده شده برای رمزنگاری-در صورت وجود- را به عنوان پارامتر می پذیرند. لازم به ذکر است نوع آخرین پارامتر بهتر است بجای varchar ، nvarchar باشد. GUID با استفاده از تابع AsymKey_ID() در دسترس قرار می گیرد. بر خلاف روش کلید متقارن در این روش نیازی به باز کردن کلید نیست.
UPDATE tblStudent
SET sname = EncryptByAsymKey(AsymKey_ID('key1'),sname)

SELECT sname,CONVERT(varchar(max),
DecryptByAsymKey(AsymKey_Id('key1'), sname , N'pass'))
AS DecryptedData
FROM tblStudent

از آنجا که طول داده های رمزنگاری شده داز است بهتر است نوع ستونی که داده ها در آن قرار می گیرد از نوع varchar(max) تعریف شود.
3-10-4 رمزنگاری با استفاده از گواهینامه
گواهینامه97 ، یک عبارت امضای دیجیتالی است که برای تعیین هویت استفاده می شود و بهترین روش شناخته شده برای ایمن ساختن وبسایت ها-با استفاده SSL98- بشمار می رود. این روش مقدار کلید عمومی را به هویت شخص ، سازمان و یا سرویسی که کلید خصوصی متناظرش را در اختیار دارد نسبت می دهد. به عنوان مثال شرکت Microsoft پس از پایان دوره های آموزشی مدرک الکترونیکی در اختیار افرادی که در این دوره ها شرکت کرده اند قرار می دهد. برای جلوگیری از جعل مدارک این شرکت از یک امضای دیجیتالی استفاده می کند. این امضا با کلید خصوصی شرکت قفل شده و با استفاده از کلید عمومی که در اختیار همگان است باز شده و امضا نمایان می شود. حال اگر فردی ادعا کند که چنین مدرکی دارد با استفاده از کلید عمومی می توان صحت و سقم این مدرک را بررسی کرد. گواهینامه ها توسط شرکت های نظیر VerSign ،Thawte و GlobalSign که به (CAs)99 معروف هستند منتشر می شوند. موجودیتی که گواهینامه را از CAs دریافت کرده صاحب100 آن گواهینامه است. گواهینامه ها حاوی یک کلید عمومی به همراه داده های اضافه نظیر اطلاعاتی در مورد مالک کلید و تاریح تولید و انقضا هستند.
برای رمزنگاری بااین روش ابتدا یک گواهینامه با استفاده ار دستور Create Certificate می ساریم. عبارت ENCRYPTION BY PASSWORD ، کلمه رمزی را که کلید خصوصی گواهینامه را رمزنگاری کرده است مشخص می کند. عبارت SRART_DATE نشان دهنده تاریخ شروع اعتبار گواهینامه است. اگر این تاریخ مشخص نشده باشد ، این تاریخ برابر با تاریخ جاری است. عبارت EXPIRY_DATE تاریخ پایان اعتبار است و تاریخ پیش فرض برای پایان اعتبار گواهینامه یک سال پس از ایجاد آن است.
CREATE CERTIFICATE MyCertificateName
ENCRYPTION BY PASSWORD = 'MyPassword'
WITH START_DATE = '07/07/2007',
EXPIRY_DATE = '08/07/2007',
SUBJECT = 'identifier'
پس از ایجاد گواهینامه ، می توان از آن برای رمزنگاری داده ها استفاده کرد که این عمل با استفاده از تابع EncryptByCert() انجام می شود. پارامتر های این تابع GUID گواهینامه -که با استفاده از تابع Cert_ID() بدست می آید- و عبارت (ویا ستون) که قرار است رمزنگاری شود می باشند.

UPDATE tblStudent
SET sname = EncryptByCert(Cert_ID('MyCertidicateName'),sname)

با استفاده از تابع DecryptByCert() می توان عبارت و یا ستون رمزنگاری شده را رمزگشایی کرد. پارامتر های این تابع GUID ، عبارت و یا ستون رمزنگاری شده و کلمه رمزی که با آن کلید خصوصی گواهینامه رمز شده است.

SELECT sname,CONVERT(varchar(max),
DecryptByCert(Cert_ID('MyCertidicateName'),sname, N'MyPassword'))
AS DecryptedData
FROM tblStudent

3-11 جمع بندی
در این فصل امنیت در SQLServer2005 بررسی شد. ابتدا انواع مدهای تعیین اعتبار بررسی شد. در ادامه مفاهیمی همچون Login ، principal ، securable ، encryption ، role ، user بررسی شد. اکثر این اعمال در سمت SQLServer انجام می شود. در فصل بعد یک سیستم عملی طراحی شده و در فصل پنجم مطالبی از امنیت که باید یک برنامه نویس مد نظر داشته باشد بررسی می شود.

فصل چهارم طراحی سیستم پرسنلی

4-1 مقدمه
در این فصل یک سیستم با عنوان سیستم پرسنلی طراحی شده است. این سیستم یک سیستم صرفا آموزشی است که برای مطالعه ارتباط امنیت موجود در SQLServer2005 و یک برنامه پایگاه داده ای ارائه شده است. برای آشنایی مقدماتی با سیستم ، یک شرکت نرم افزاری متشکل از تعدادی پرسنل را در نظر بگیرید که تعدادی پروژه در دست دارد. پروژه به افراد محول می شود. این سیستم نیاز به مکانیزمی برای مدیریت افراد و پروژه های مختلف دارد بدین معنی که اعمال ثبت ، ویرایش ، جستجو و حذف پروژه و پرسنل باید در سیستم تعبیه شود. در ضمن باید اطلاعات مربوط به پروژه های محول شده به افراد را بتوان مدیرت کرد بدین معنی که چه پروژه ای به چه شخصی محول شده است. این قسمت نیز باید شامل اعمال ثبت ، ویرایش ، جستجو و حذف باشد. در ذیل سلسله مراتب طراحی این سیستم آورده شده است.

4-2 UseCase
در ذیل UseCase مربوط به سیستم پرسنلی را مشاهده می کنید :

شکل 4-1 : usecase
4-2-1 شرح UseCase
ثبت
1. کاربر از روی فرم اصلی ، فرم مورد نظر خود را انتخاب می کند.
* فرم نمایش داده می شود.
2. کاربر اطلاعات مربوطه وارد می کند.
3. کاربر دکمه ثبت را می فشارد.
* اطلاعات در پایگاه داده ثبت می شوند.
* پیغام مناسب نمایش داده می شود.
4. پایان
ویرایش
1. کاربر از روی فرم اصلی ، فرم مورد نظر خود را انتخاب می کند.
* فرم نمایش داده می شود.
2. کاربر اطلاعات را ویرایش می کند.
3. کاربر دکمه ثبت را می فشارد.
* اطلاعات در پایگاه داده ثبت می شوند.
* پیغام مناسب نمابش داده می شود.
4. پایان

حذف
1. کاربر از روی فرم اصلی ، فرم مورد نظر خود را انتخاب می کند.
* فرم نمایش داده می شود.
2. کاربر کلید اصلی را برای انجام عمل حذف وارد می کند..
3. کاربر دکمه حذف را می فشارد.
* اطلاعات از پایگاه داده حذف می شوند.
* پیغام مناسب نمابش داده می شود.
4. پایان

جستجو
1. کاربر از روی فرم اصلی ، فرم مورد نظر خود را انتخاب می کند.
* فرم نمایش داده می شود.
2. کاربر دکمه جستجو را می فشارد.
* اطلاعات بر روی فرم نمایش داده می شوند
3. پایان

4-3 نمودار توالی

شکل 4-2 : نمودار توالی برای انجام عمل ثبت پرسنل

شکل 4-3 : نمودار توالی برای انجام عمل حذف پروژه

شکل 4-4 : نمودار توالی برای انجام عمل جستجو بر روی پروژه های محرل شده به افراد

شکل 4-5 : نمودار توالی برای انجام عمل جستجو بر روی پرسنل
بقیه نمودار های توالی نیز همانند شکل های فوق است.

4-4 Class Diagram
ارتباط کلاس ها در شکل 4-4 نشان داده شده است :

شکل 4-4 : class diagram

4-5 واژه نامه داده ای

نمونه داده
توضیح
نوع فیلد
نام فیلد
1
شماره پرسنلی
varchar
Id
یاشار
نام
varchar
fname
زرگری زنوز
نام خانوادگی
varchar
lname
09121782836
موبایل
varchar
mobile
نرم افزار
رشته
varchar
field
مدیر
سمت
varchar
position
لیسانس
مدرک
varchar
madrak
تهران سعادت آباد
آدرس
varchar
address
nirvana_pishva@yahoo.com
پست الکترونیکی
varchar
email

جدول 4-1 : واژه نامه داده ای مربوط به پرسنل

نمونه داده
توضیح
نوع فیلد
نام فیلد
منابع مالی
نام پروژه
varchar
projectname
سهند زرگری
نام مدیر
varchar
manager
01/01/85
تاریخ شروع
varchar
start
01/01/86
تاریخ پایان
varchar
finish
20%
درصد پیشرفت
varchar
progress
آیدین زرگری
کارفرما
varchar
employer

توضیح
varchar
desc
جدول 4-2 : واژه نامه داده ای مربوط به پروژه

نمونه داده
توضیح
نوع فیلد
نام فیلد
یاشار زرگری
نام شخص
varchar
lname
منابع مالی
نام پروژه
varchar
project
01/01/85
تاریخ اخذ
varchar
start
01/01/86
تاریخ تحویل
varchar
finish
5000000000$
قیمت پیشنهادی
varchar
price

توضیح
varchar
descr
جدول 4-3 : واژه نامه داده ای مربوط به اخذ پروژه

فصل پنجم معرفی نرم افزار و بررسی موانع هنگام برنامه نویسی

5-1 مقدمه
در این فصل به معرفی نرم افزار می پردازیم. این نرم افزار دارای پنج فرم با نام های ورود (frm_begin) ، پرسنل (frm_person) ، پروژه (frm_project) ، اخذ پروژه (frm_person_project ) و یک فرم اصلی است. فرم های Login و فرم پرسنل به طور کامل توضیح داده می شوند. روش کار در بقیه فرم ها مشابه فرم پرسنل است. در صورت وجود مغایرت ، توضیحات لازم داده خواهد شد. برای درک مفاهیم این فصل لازم است تا فصل سوم به دقت مطالعه شود.
5-2 رشته ارتباط101
برای ارتباط با پایگاه داده از محیط های برنامه نویسی دات نتی باید ابتدا یک ارتباط102 ایجاد کنیم. برای این کار نیاز به یک رشته ارتباط (CS) داریم. این رشته شامل مجموعه ای از مقادیر است که با یک عملگر "=" به صفات خود نگاشت می شوند. نام پایگاه داده و نام سرویس دهنده نمونه هایی از این صفات هستند. این رشته به دو شکل ساخته می شود:
* Windows authentication mode(NT Authentication) : در این روش کاربری که به ویندوز Login شده است می تواند به پایگاه داده وصل شود. در واقع در این روش با مد هویت شناسی ویندوز با SQL Server ارتباط برقرار می شود. در ذیل نمونه ای از این رشته را مشاهده می کنید :
"Data Source=yashar;Initial Catalog=myDb;Integrated Security=True"
شما عموما مدیر-admin- کامپیوتر خود هستید. هنگام کار با مد هویت شناسی ویندوزی کاربری با این سطح در واقع در SQLServer همه کاره است و قادر به انجام هر عملی می باشد. از آنجا که سطح اختیار کاربران در یک سیستم چند کاربره متفاوت است بنابراین اگر سیستم چند کاربره طراحی کرده اید و از هویت شناسی ویندوزی استفاده می کنید ، سطح اختیار هر کاربر باید توسط مدیر شبکه به دقت تعیین شود که این عمل در سطح سیستم عامل ویندوز انجام می شود. برای کسب اطلاع بیشتر به بخش 3-2 مراجعه شود.
* SQlServer authentication mode : در این روش با هویت شناسی توسط SQLServer به پایگاه داده وصل می شوند. در این روش به این علت که نام کاربر و کلمه رمز در رشته قید می شود ، از میزان امنیت پایین تری نسبت به مد هویت شناسی ویندوزی برخوردار است و این شیوه برای برقراری با پایگاه داده پیشنهاد نمی شود و بهتر است با استفاده از امنیت یکپارچه ویندوز103 این رشته ساخته شود. در ذیل نمونه ای از این رشته را مشاهده می کنید:
"Data Source=yashar;Initial Catalog=myDb;User ID=myLogin;Password='plm789';Network Library=dbmslpcn "
نام کاربر موجود در رشته در واقع یک Login ، در سطح SQLServer است. اختیارات این کاربر باید محدود باشد. برای این کار هنگام تعریف این Login در SQLServer آنرا در گروه public قرار می دهیم. هر Login بصورت پیش فرض در این گروه قرار دارد و این گروه کمترین اختیار را نسبت به سایر گروه ها در سطح سرویس دهنده دارد. برای تعریف Login به 3-3 مراجعه شود.
5-3 ارتباط برنامه با نقش برنامه ای(APR)
همانطور که در بخش 3-5-3 گفته شد APR ها برای محدود کردن دسترسی یک برنامه به منابع پایگاه داده استفاده می شود. APR ها بهترین و امن ترین روش برای دسترسی برنامه ها به پایگاه داده است. روش های سنتی بکار رفته کاملا اشتباه بوده و به تنهایی کارایی ندارند. به راحتی چنین سیستم هایی می توانند مورد تهاجم قرار گیرند. برای روشن شدن موضوع به بررسی یکی از روش های سنتی می پردازیم و در ادامه چگونگی انجام این کار با استفاده از APR بررسی می کنیم.
یکی از روش های سنتی به این صورت است که ابتدا در پایگاه داده یک جدول در پایگاه داده ساخته می شود که دارای سه ستونِ نام کاربر ، کلمه رمز و شماره است(شکل 5-1 ).

شکل 5-1 : استفاده از جدول پایگاه داده ، برای تامین امنیت در روش سنتی

هنگامی که کاربری نام کاربر و کلمه رمز را وارد می کند ، این اطلاعات با داده های موجود در جدول مقایسه شده و در صورت سازگاری ، داده موجود در ستون شماره به محیط برنامه بازگردانده می شود. این عدد مشخص کننده سمت کاربر است. بر فرض مثال اگر این عدد معادل دو باشد ، این کاربر سمت کارمند عادی را دارد. با استفاده از این عدد دسترسی به منابع برنامه ( TextBox ، Button ، …) با غیرفعال کردن آنها محدود می شود. اغلب برای غیر فعال کردن منابع ، در پنجره properties گزینه disable انتخاب می شود. شکستن این سد برای هکر ها کار دشواری نبوده و استفاده از این روش ، امنیت منابع موجود در پایگاه داده را به خطر می اندازد در عوض اگر تامین امنیت به SQLServer واگذار شود ، کسی به راحتی نمی تواند از سد آن عبور کند. تعدادی از این اعمال بصورت خودکار توسط SQlServer انجام می شود و تعدادی نیز باید توسط مدیر SQlServer انجام شود که در فصل 3 به تعدادی از آنها اشاره شد. قبل از بررسی این بخش لازم است با مراجعه به 3-5-3 نحوه ایجاد و مدیریت نقش های برنامه ای را به دقت مطالعه کرد. در اینجا به بررسی نحوه ارتباط برنامه با نقش برنامه ای و پیاده سازی آن در محیط پایگاه داده می پردازیم :
1. کاربر برنامه(سرویس گیرنده) مورد نظر را اجرا می کند.
2. برنامه تحت عنوان یک کاربر عادی به نمونه ای از SQLServer وصل می شود. برای این کار یک Login ساخته و دسترسی به پایگاه داده مورد نظر به آن داده می شود. این Login همانطور که قبلا هم گفته شد می تواند username های ویندوز باشد و یا یکی از Login های موجود در SQLServer باشد. بر روی User Mapping کلیک کرده و دسترسی به پایگاه داده های مورد نظر به Login داده می شود. در این صورت کاربری همنام با Login ساخته می شود(این کاربر ، کاربری در سطح پایگاه داده است و می توان هر کاربر دیگری را در سطح آن پایگاه داده برای این کار انتخاب کرد). به شکل های 5-1 و 5-2 توجه شود.

شکل 5-1: ساختن Login
همانطور که در شکل 5-2 نیز مشخص است ، این کاربر پایگاه داده عضو نقش پایگاه داده ای public است. اعضای این نقش تنها به منابع عمومی دسترسی دارند و دارای کمترین دسترسی ها برای آنها تعریف شده است.

شکل 5-2 : ایجاد کاربر در سطح پایگاه داده
3. کاربر موجود در پایگاه داده master باید اجازه اجرای sp_setapprole را داشته باشد و از دسترسی به سایر منابع باید محروم باشد. برای انجام این کار بر روی کاربر Login1 کلیک راست کرده و Properties را انتخاب کنید(شکل 5-3).

شکل 5-3 : اجازه اجرای sp_setapprole به کاربر Login1 اعطا شده است
4. برنامه رویه ذخیره شده sp_setapprole را اجرا می کند. این رویه نام و کلمه رمز APR را از فرم ورود دریافت می کند(شکل 5-4).

شکل 5-4 : در یافت نام APR و کلمه رمز
کد های زیر به زبان برنامه نویسی C# بوده و برای اجرای sp_setapprole است.
public partial class frm_begin : Form
{
public static SqlConnection con;
public SqlCommand cmd_SP;
public frm_begin()
{
String s = "Data Source=y;Initial Catalog=db_systemactivity;Integrated Security=True";
String s1 = "Data Source=y;Initial Catalog=db_systemactivity;User ID=u;Password='1';Network Library=dbmslpcn";
con = new SqlConnection(s1);
InitializeComponent();
}
//**************************************************************
private void btn_ok_Click(object sender, EventArgs e)
{
cmd_SP = con.CreateCommand();
cmd_SP.CommandType = CommandType.StoredProcedure;
cmd_SP.CommandText = "sp_setapprole";
cmd_SP.Parameters.Add("@rolename", SqlDbType.NVarChar).Value = txt_username.Text;
cmd_SP.Parameters.Add("@password", SqlDbType.NVarChar).Value = txt_password.Text;
con.Open();
cmd_SP.ExecuteNonQuery();
s1 = true;
//con.Close();
}

دقت کنید که SqlConnection بصورت static تعریف شده است علت این امر این است که Connection مورد نظر(con) تحت کنترل یکی از APR های معتبر در سطح پایگاه داده در آمده است و حوزه عملیاتی این Connection معادل حوزه عملیاتی APR است. حال فرض کنید فرمی دارید که مشخصات پرسنل یک شرکت را ثبت می کند. این فرم یا باید یک Connection جدید بسازد و یا باید از Connection این کلاس frm_begin استفاده کند. اگر قرار باشد تا برای این فرم یک Connection جدید ساخته شود دوباره باید از UserName و Password از کاربر درخواست شود(اگر تعداد فرم ها زیاد باشد این عمل بسیار وقت گیر است) و یا اینکه UserName و Password از کلاس frm_begin به کلاس جاری منتقل شود. این انتقال می تواند بسیار مهلک باشد و انتقال این اطلاعات در سطح فرم ها از لحاظ امنیتی مناسب نیست. بهترین روش استفاده از Connection موجود در کلاس frm_begin است. راه های متفاوتی برای انجام این کار وجود دارد که یکی از آنها تعریف Connection بصورت static است. به این نکته نیز توجه شود که این Connection نباید تا پایان کار کاربر بسته شود و لزومی به اجرای دستور con.Close() نیست.
5. در صورتی که این نام و کلمه رمز معتبر باشد ، APR مورد نظر فعال می شود.
6. در این لحظه ارتباط کاربر عادی قطع شده و برنامه با سطح دسترسی APR به SQLServer وصل می شود. پس از اجرای این رویه ، connection برنامه تحت کنترل نقش مورد نظر قرار می گیرد بدین معنی که اگر بر فرض مثال نقش برنامه ای مجاز به دسترسی به جدول tbl1 نباشد ، پس از اجرای sp_setapprole ، این connection نیز حق دسترسی به این جدول را ندارد.

5-4 معرفی فرم پرسنل
این فرم مشخصات پرسنل را دریافت کرده و اعمال select,updatet,delete,insert را انجام می دهد(شکل5-5).

شکل 5-5 فرم پرسنل
تمامی اعمال یاد شده بجز delete با استفاده از store procedure انجام شده است. این رویه ها از تهاجم ها در امان هستند. در سطح SQLServer مدیر SQLServer با تعریف دقیق نقش ها و کاربران پایگاه داده این کار را انجام داده است. ممکن است مدیر به کاربری دسترسی به این منابع را داده باشد و کاربری دیگر را از این دسترسی ها محروم کرده باشد. با این کار افرادی که مستقیما و بدون واسط به SQLServer وصل می شوند تنها در صورتی می توانند به منابع دسترسی داشته باشند که مدیر آن دسترسی ها را مجاز شمارد و اگر فردی بخواهد از طریق برنامه به منابع دسترسی داشته باشد باز هم مدیر با تعریف نقش های برنامه ای این دسترسی را محدود می کند. به طریقه استفاده از Connection در این فرم توجه شود. این Connection بصورت frm_begin.con فراخوانی شده است. علت این امر این است که con از نوع stastic تعریف شده است و برای دسترسی به منابع static در زبان برنامه نویسی C# باید نگارش calssName.Object استفاده شود.در ذیل کدهای این فرم را که بزبان C# است را مشاهده می کنید.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Drawing;
using System.Data;
using System.Text;
using System.Windows.Forms;
using System.Data.SqlClient;

namespace PersonalSystem
{
public partial class frm_person : UserControl , Icommand
{
private frm_person frmperson;
private SqlCommand cmd_insert;
private SqlCommand cmd_select;
private SqlCommand cmd_update;
private SqlCommand cmd_delete;
private SqlCommand cmd_SP;
private SqlDataAdapter da;
private DataTable dt;
public frm_person()
{
da = new SqlDataAdapter();
dt = new DataTable();
cmd_insert = frm_begin.con.CreateCommand();

InitializeComponent();
}
//****************************************************
public void insert(String spName)
{
try
{
cmd_insert = frm_begin.con.CreateCommand();
cmd_insert.CommandType = CommandType.StoredProcedure;
cmd_insert.CommandText = spName;
cmd_insert.Parameters.Add("@Id", SqlDbType.Text).Value = txt_id.Text;
cmd_insert.Parameters.Add("@fname", SqlDbType.VarChar).Value = txt_fname.Text;
cmd_insert.Parameters.Add("@lname", SqlDbType.VarChar).Value = txt_lname.Text;
cmd_insert.Parameters.Add("@mobile", SqlDbType.VarChar).Value = txt_mob.Text;
cmd_insert.Parameters.Add("@field", SqlDbType.VarChar).Value = combo_field.Text;
cmd_insert.Parameters.Add("@position", SqlDbType.VarChar).Value = combo_position.Text;
cmd_insert.Parameters.Add("@madrak", SqlDbType.VarChar).Value = combo_madrak.Text;
cmd_insert.Parameters.Add("@address", SqlDbType.VarChar).Value = txt_add.Text;
cmd_insert.Parameters.Add("@email", SqlDbType.VarChar).Value = txt_email.Text;

cmd_insert.ExecuteNonQuery();
}
catch(Exception ex)
{
if (ex.Message.Contains("EXECUTE permission denied on object 'sp_insert', database 'db_systemactivity', schema 'dbo'."))
MessageBox.Show("شما مجاز به وارد کردن اطلاعات در پایگاه داده نیستید. برای اطلاعات بیشتر با مدیر پایگاه داده تماس بگیرید.", "خطا",
MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
public void SaveItem()
{

insert("sp_insert");
MessageBox.Show(".عمل ذخیره سازی انجام شد", "پیام",
MessageBoxButtons.OK, MessageBoxIcon.Information);

// String s = "insert into tbl_person (Id,fname,lname,mobile,field,position,madrak,address,email) values (EncryptByCert(Cert_ID('c1'),'" + txt_id.Text + "'),'" + txt_fname.Text + "','" + txt_lname.Text + "','" + txt_mob.Text + "','" + combo_field.Text + "','" + combo_position.Text + "','" + combo_madrak.Text + "','" + txt_add.Text + "','" + txt_email.Text + "')";
// cmd_insert = new SqlCommand(s, frm_begin.con);
// //frm_begin.con.Open();
// cmd_insert.ExecuteNonQuery();
// MessageBox.Show("عمل ذخیره سازی انجام شد");
//// frm_begin.con.Close();

}
//****************************************************
public void DeleteItem()
{
try
{
string slct;
slct = " DELETE FROM tbl_person WHERE lname = '" + txt_lname.Text + "'";
cmd_delete = new SqlCommand(slct, frm_begin.con);
cmd_delete.ExecuteNonQuery();
MessageBox.Show("عمل حذف انجام شد", "پیام",
MessageBoxButtons.OK, MessageBoxIcon.Information);
}
catch (Exception ex)
{
if (ex.Message.Contains("DELETE permission denied on object 'tbl_person', database 'db_systemactivity', schema 'dbo'."))
MessageBox.Show("شما مجاز به حذف اطلاعات از پایگاه داده نمی باشید. برای کسب اطلاعات بیشتر با مدیر پایگاه داده تماس بگیرید.", "خطا",
MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
//****************************************************
public void select(String spName)
{
try
{
cmd_select.CommandType = CommandType.StoredProcedure;
cmd_select.CommandText = spName;
cmd_select.ExecuteNonQuery();
da.SelectCommand = cmd_select;
da.Fill(dt);
dataGridView1.DataSource = dt;
dataGridView1.Columns[0].HeaderText = "شماره پرسنلی";
dataGridView1.Columns[0].Width = 120;
dataGridView1.Columns[1].HeaderText = "نام";
dataGridView1.Columns[1].Width = 110;
dataGridView1.Columns[2].HeaderText = "نام خانوادگی";
dataGridView1.Columns[2].Width = 110;
dataGridView1.Columns[3].HeaderText = "تلفن همراه";
dataGridView1.Columns[3].Width = 110;
dataGridView1.Columns[4].HeaderText = "رشته";
dataGridView1.Columns[5].HeaderText = "سمت";
dataGridView1.Columns[6].HeaderText = "مدرک";
dataGridView1.Columns[7].HeaderText = "آدرس";
dataGridView1.Columns[7].Width = 200;
dataGridView1.Columns[8].HeaderText = "پست الکترونیکی";
dataGridView1.Columns[8].Width = 200;
}
catch (Exception ex)
{
if (ex.Message.Contains("EXECUTE permission denied on object 'sp_select', database 'db_systemactivity', schema 'dbo'."))
{
MessageBox.Show("شما اقدام به مشاهده داده های غیر مجاز کرده اید. انجام چنین عملی از سمت پایگاه داده محدود شده است", "خطا",
MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
}
public void SearchItem()
{

cmd_select = frm_begin.con.CreateCommand();
dt.Clear();
if (txt_pass.Text != "")
{
cmd_select.Parameters.Add("@pass", SqlDbType.NVarChar).Value = txt_pass.Text;
select("sp_select");
}
else
{
select("sp_select1");
}
}
//****************************************************
}
}

5-5 رمز نمودن اطلاعات
همانطور که گفته شد اطلاعات توسط رویه های ذخیره شده در پایگاه داده ذخیره می شوند. در ذیل رویه ای که بر ی ذخیره اطلاعات پرسنل بکار رفته را مشاهده می کنید.
CREATE PROCEDURE sp_insert
@Id varchar(50) ,
@fname varchar(50) ,
@lname varchar(50) ,
@mobile varchar(max) ,
@field varchar(50) ,
@position varchar(50) ,
@madrak varchar(50) ,
@email varchar(max),
@address varchar(max)
AS
BEGIN
INSERT INTO tbl_person (Id,fname,lname,mobile,field,position,madrak,address,email) values (@Id,@fname,@lname,EncryptByCert(Cert_ID('c1'),@mobile),@field,@position,@madrak,@address,@email)
END
در این رویه شماره تلفن همراه بصورت رمزنگاری شده در پایگاه داده ذخیره می شود. رمزنگاری با استفاده از گواهینامه انجام شده است و نام آن c1 است. برای مشاهده فیلد تلفن همراه نیز باید از گواهینامه c1 استفاده شود. در ضمن باید کلمه رمز گواهینامه نیز موجود باشد. @pass برای دریافت کلمه رمز تعبیه شده است. بهتر است نوع آن nvarchar تعریف شود.
CREATE PROCEDURE sp_select
@pass nvarchar(50)
AS
BEGIN
SELECT Id,fname,lname,CONVERT(varchar(max),DecryptByCert(Cert_ID('c1'),mobile,@pass))AS mobile,field,position,madrak,address,email from tbl_person
END

شکل5-6 : اعطای دسترسی به نقش برنامه ای manager
به کاربر باید اختیار استفاده از گواهینامه داده شود و در واقع این اختیار باید به APR متناظر با این کاربر داده شود(شکل5-6 ).
در فرم هایی دیگر از متدهای دیگری برای رمزنگاری استفاده شده است. در فرم پروژه رمزنگاری با استفاده از کلید نامتقارن و در فرم اخذ پروژه این عمل با استفاده از کلید متقارن انجام شده است. هنگام استفاده از هر یک باید دسترسی ها صریحا به نقش مورد نظر داده شود به عبارت دیگر اگر از کلید متقارن ، کلید نا متقارن و یا هر متد دیگری برای رمز نگاری استفاده می کنید باید دسترسی به کلید متقارن ، کلید نا متقارن همانند شکل 5-6 به نقش مورد نظر داده شود تا این کاربر بتواند اعمال لازم را بر روی داده ها انجام دهد. فرم های دیگر و حوزه عملیاتی آنها مشابه فرم پرسنل است و نیازی به توضیح بیشتر نمی باشد. برای مطالعه روش های رمزنگاری به بخش (3-10) مراجعه شود.
5-6 کار با استثناها
در این سیستم هیچ کاربری از فشردن دکمه و یا انجام عملی در محیط برنامه منع نشده است. محدودیت ها فقط از سمت پایگاه داده اعمال می شود. در این سیستم دو کاربر وجود دارند که یکی دارای دسترسی کامل است. نام این کاربر manager است و قادر به انجام هر عملی در برنامه می باشد. در واقع manager همان APR است که دسترسی به تمامی منابع به آن داده شده است. عنوان کاربر دوم employee است که بسیاری از اختیارات از جمله اجرای رویه کنترلی sp_insert از وی سلب شده است و این کاربر قادر به ذخیره سازی اطلاعات مربوط به پرسنل نمی باشد. این کاربر هنگام اجرای برنامه همان اطلاعاتی را مشاهده می کند که کاربر manager مشاهده می کند با این تفاوت که اگر این کاربر اقدام به ذخیره سازی اطلاعات کند پیغامی از سمت SQLServer مبنی بر اینکه کاربر مجاز به اجرای رویه کنترلی sp_insert نمی باشد به برنامه ارسال می شود. به این پیغام خطا ، استثناء گفته می شود. این خطا در هنگام اجرای برنامه باعث ایجاد اختلال در اجرای عادی برنامه می شود. در ضمن این پیغام به زبان انگلیسی بوده و قابل فهم برای یک کاربر غیر متخصص نمی باشد. برای مقابله با این مشکل از بلوک های try , catch استفاده می شود. با استفاده از این امکان می توان از نمایش پیغام خطا ارسالی از سمت SQLServer جلوگیری کرده و به جای آنها پیام های فارسی قابل فهم چاپ کرد. در ضمن با این کار مانع خاتمه برنامه در صورت مواجه شدن با یک استثنا می شویم. هر چه مدیریت استثناها بخوبی انجام شود کیفیت اجرایی برنامه بالا می رود و استثناها باعث قطع غیر عادی برنامه نمی شود. در کدهای فوق این استثناها تا حد امکان مدیریت شده اند ولی کنترل دقیق مستلزم اجرای آزمایشی برنامه در یک محیط عملی است. کاربران در مدت کار با نرم افزار در صورت مشاهده پیغام های نامفهوم آنها را کارشناس نرم افزار گزارش می دهند و درصد این خطاها پس از مدتی به دلیل اصلاحات بعمل آمده به میزان بسیار زیادی کاهش می یابد. نمونه ای از پیغام خطا ارسالی از سوی SQLServer و پیغام معادل آن بزبان فارسی در ذیل آورده شده است. برای آشکار شدن موضوع به مثال زیر توجه کنید :
فرض کنید کاربری با عنوان employee اجازه وارد کردن داده در پایگاه داده را ندارد. برای اعمال چنین محدودیتی ، در نقش برنامه ای که برای این گروه از کاربران تعریف شده دسترسی به رویه ذخیره شده متناظر با این عمل ، سلب شده است(شکل 5-7).

شکل 5-7 : دسترسی به sp_insert برای نقش برنامه ای employee غیر مجاز است
برای اینکه دریابیم در صورتی که این کاربر این رویه را انجام دهد چه پیغامی از سمت SQLServer صادر می شود ، باید خطوطی از کدهای برنامه را که چنین عملی را انجام می دهند را خارج از بلوک try & catch قرار داد. هنگامی که کاربر اقدام به وارد کردن داده در پایگاه داده می کند با استثنایی مواجه می شود و پیغامی مانند شکل 5-8 صادر می شود.

شکل 5-8 :نمونه ای از پیغام خطای صادر شده از SQLServer
پس از مشاهده پیغام خطا ، باید به نحوی خطوط کد برنامه را در بلوک های try & catch قرار داد تا در صورت بروز استثنا روال طبیعی برنامه دنبال شود و پیغام قابل درک برای کارب ارسال شود.
به کدهای زیر توجه شود :
public void insert(String spName)
{
try
{
cmd_insert = frm_begin.con.CreateCommand();
cmd_insert.CommandType = CommandType.StoredProcedure;
cmd_insert.CommandText = spName;
cmd_insert.Parameters.Add("@Id", SqlDbType.Text).Value = txt_id.Text;
cmd_insert.Parameters.Add("@fname", SqlDbType.VarChar).Value = txt_fname.Text;
cmd_insert.Parameters.Add("@lname", SqlDbType.VarChar).Value = txt_lname.Text;
cmd_insert.Parameters.Add("@mobile", SqlDbType.VarChar).Value = txt_mob.Text;
cmd_insert.Parameters.Add("@field", SqlDbType.VarChar).Value = combo_field.Text;
cmd_insert.Parameters.Add("@position", SqlDbType.VarChar).Value = combo_position.Text;
cmd_insert.Parameters.Add("@madrak", SqlDbType.VarChar).Value = combo_madrak.Text;
cmd_insert.Parameters.Add("@address", SqlDbType.VarChar).Value = txt_add.Text;
cmd_insert.Parameters.Add("@email", SqlDbType.VarChar).Value = txt_email.Text;

cmd_insert.ExecuteNonQuery();
}
catch(Exception ex)
{
if (ex.Message.Contains("EXECUTE permission denied on object 'sp_insert', database 'db_systemactivity', schema 'dbo'."))
MessageBox.Show("شما مجاز به وارد کردن اطلاعات در پایگاه داده نیستید. برای اطلاعات بیشتر با مدیر پایگاه داده تماس بگیرید.", "خطا", MessageBoxButtons.OK,MessageBoxIcon.Error);
}
پیغامی که کاربر مشاهده می کند همانند شکل 5-9 است.

شکل 5-9 : نمونه ای از پیغام صادر شده توسط برنامه نویس
ممکن است تعدادی از این استثناها در مرحله نخست در نظر گرفته نشده باشند ولی در طی زمان در صورت مواجه شدن با هر یک از آنها می توان روالی مانند آنچه در که در بالا گفته شد در پیش گرفته شود. پس گذشت مدت آزمایشی بارفع شدن این خطاها کیفیت اجرایی برنامه بالا می رود.
5-7 جمع بندی
برای برقراری امنیت برنامه هنگام اتصال به SQLServer باید اعمال زیر انجام شود :
1. ایجاد نقش برنامه ای با سطح دسترسی مناسب
2. اجرای رویه ذخیره شده sp_setapprole از داخل کد برنامه و محصور کردن ارتباط مورد نظر
تعریف دقیق سطوح دسترسی مهم ترین امر در ایجاد امنیت می باشد. مدیریت استثناها یک مساله مهم در بالا بردن قدرت اجرایی برنامه است.

فصل ششم نتیجه گیری و راهکارهای آینده

امنیت یکی از مهمترین مساله دنیا و تکنولوژی روز است. این مساله به قدری حیاتی است که اگر برآورده نشود جامعه صدمات زیادی را متحمل می شود. متاسفانه در کشور ایران به مساله امنیت بهای کمی داده می شود. بسیاری از برنامه های کامپیوتری که توسط شرکت های نرم افزاری تهیه می شود ، از درجه امنیت پایینی برخوردار هستند. این برنامه ها پس از تزریق به بازار تجاری پس از مدتی به علت مشکلات امنیتی که دارند اغلب از رده خارج می شوند و در ضمن شرکت ها و سازمان های دیگر را دچار مشکل می کنند.
در سازمان هایی که از شبکه های کامپیوتری استفاده می کنند ، عدم وجود مدیران متخصص در سطح شبکه و سیستم عامل و پایگاه داده باعث ایجاد بسیاری از ناامنی ها شده است. اگر مدیرانی در سطح پایگاه داده بانک ها موجود نباشد ممکن است سرقت های بزرگی از سازمان ها انجام شود. سرقت ها فقط بصورت مادی نیست. افشای اطلاعات نظامی یک کشور ممکن است منجر به نابودی یک کشور بیانجامد. افشای اطلاعات اقتصادی می تواند جامعه را با سرحد فقر پیش ببرد. اکنون جامه ما در حال گذر از یک جامعه سنتی و تبدیل شدن به یک جامعه کامپیوتری است و همانطور که نیاز به سازمانی برای بررسی کیفیت ساختمان ها در برابر زلرله ایجاد شده است نیاز به سازمان هایی برای بررسی کیفیت نرم افزار ها نیز امری حیاتی به نظر می رسد. راهکارهای زیر برای ایجاد یک جامعهِ امن نرم افزاری ارائه شده است. باشد که لازم لاجرا شوند :
1. ایجاد سازمانی مانند استاندارد ، برای بررسی کیفیت نرم افزارهایی که قرار است وارد بازار شوند.
2. استفاده از دانشگاه ها و مراکز تحقیقاتی برای ارائه راه حل هایی در جهت پیشبرد کیفیت نرم افزار و تقویت مولفه هایی نظیر امنیت نرم افزار
3. اهمیت دادن سازمان ها و مراکزی که از کامپیوتر استفاده می کنند به مساله امنیت شبکه های کامپیتری و نرم افزارها
4. استفاده از مدیران امنیت مجرب و دانا در سازمان ها
5. انجام تحقیقات بر روی ابزارهای اعمال امنیت بر روی داده نظیر SQLServer و Oracle
6. انجام تحقیفات بر روی امنیت کلاسیک
7. استفاده از دانش و ابزار روزِ امنیت
8. ایجاد پلیس نرم افزاری برای شناسایی افراد مهاجم به کامپیوترهای سازمان ها

در این پایان نامه بسیاری از مفاهیم به خوبی بررسی شده است و سیاست های تشخیص و مبتنی بر نقش در محیط SQLServer نشان داده شده است ولی طریقه پیاده سازی سیاست اجباری به خوبی بررسی نشده است. به نظر نگارنده بررسی دقیق شِما در SQLServer برای مطالعه سیاست اجباری ضروری است.

منابع و ماخذ

1. Robin Dewson , "Beginning SQL Server 2005 for Developers From Novice to Professional" , Apress , year 2006
2. Rajesh George and Lance Delano ," SQL Server 2005 Express edition STARTER KIT", Wiley ,year 2005
3. Ravi s.Sandhu and Pierangela Samarati , "Access control principle and practice" , IEEE communication magazin , year 1994
4. Andrew Watt, "Microsoft SQL Server 2005 FOR DUMMIES", WILEY , 2006
5. Bob Beauchemin , Niels Berglund and Dan Sullivan , "A First Look at SQL Server 2005 for Developers" , Addison – Wesley , year 2005
6. Thomas Rizzo, Adam Machanic,Julian Skinner , Louis Davidson,Robin Dewson, Jan Narkiewicz , Joseph Sack and Rob Walters , " Pro SQL Server 2005", Apress, year 2006
7. Stephen Dranger, Robert H. Sloan , and Jon A. Solworth / "The Complexity of Discretionary Access Control"/ 2004
8. Jonathan D. Moffett, "Specification of Management Policies and Discretionary Access Control", 2002
9. Fort George G.Meade and Patrick R. Gallagher , "A GUIDE TO UNDERSTANDING DISCRETIONARY ACCESS CONTROL IN TRUSTED SYSTEMS" , National Computer Security Center , year 1987
10. Principal ,Microsoft SQLServer2005 Books Online/DataBase Engin / Database Engin Concept / Security Considerations for Databases and Database Applications / Principal , Microsoft Corporation , last visit September 2007
11. Securable Microsoft SQLServer2005 Books Online/DataBase Engin / Database Engin Concept / Security Considerations for Databases and Database Applications / Securable, Microsoft Corporation , last visit September 2007
12. Permition ,Microsoft SQLServer2005 Books Online/DataBase Engin / Database Engin Concept / Security Considerations for Databases and Database Applications /Permition Securable, Microsoft Corporation , last visit September 2007
13. Encryption , Microsoft SQLServer2005 Books Online/DataBase Engin / Database Engin Concept / Security Considerations for Databases and Database Applications / Encryption, Microsoft Corporation , last visit September 2007
Threat-1
2- access control
3- authentication
4- auditing
administration-5
access matrix-6
7- Secrecy
Integrity-8
Improper release of information-9
Improper modification of data-10
Flow control-11
Inference control-12
Access control-13
Query-14
Security policies-15
Subject-16
Object-17
Principle-18
Grant-19
Revoke-20
Access rules-21
Access limitation-22
Minimum privilege policy-23
Maximum privilege policy-24
Closed system-25
Open system-26
Rights-27
Mutual exclusion -28
legitimate-29
reference monitor-30
31- authorization data base
Security administrator-32
33- activity
privilege-34
Access right-35
Access mode-36
Discretionary policy-37
Mandatory policy-38
Role-base policy-39
Flow of information-40
High level object-41
Low level object-42
Hierarchical-43
Classification level-44
Category -45
Integrity level-46
Crucial-47
Important -48
Unknown -49
Role -50
Logical independency-51
Windows authentication mode -52
Mixed mode -53
Username ID-54
Password-55
Validate-56
Administrator-57
Trusted Connection-58
Remote-59
Work group-60
Internet-base application-61
62- Network Domain
63- Grant
User-64
Server-65
User-66
Fixed Server Role-67
Database Role-68
Application Role-69
Task-70
System Administrator-71
Create-72
Alter -73
Drop -74
Restore-75
Grant-76
Revoke-77
78- Changing Option
Back up-79
User-defined tables-80
Data Definition Language-81
Public objects-82
Store Procedure-83
Schema-84
Namespace-85
Definition scope-86
Security identifier-87
Function-88
Store procedure-89
Encrypt-90
Decrypt-91
Password encryption-92
Asymmetric key encryption-93
Symmetric key encryption-94
Certificate encryption-95
Globally unique identifier-96
Certificate-97
Secure Sockets Layer-98
Certification Authorities-99
Subject-100
Connection String-101
Connection-102
Windows integrated security-103
—————

————————————————————

—————

————————————————————

16

1