جستجو در تالارهای گفتگو

در حال نمایش نتایج برای برچسب های 'sql'.



تنظیمات بیشتر جستجو

  • جستجو بر اساس برچسب

    برچسب ها را با , از یکدیگر جدا نمایید.
  • جستجو بر اساس نویسنده

نوع محتوا


تالارهای گفتگو

  • قوانین، اطلاعیه و ارتباط با مدیریت
    • قوانین و مقررات
    • پیشنهاد و انتقاد
    • ارتباط با مدیریت و مسئولین
    • اخبار و اطلاعیه ها
    • گروه کاربری طلایی
  • بخش ویژه (دسترسی تنها برای اعضای ویژه)
    • مسائل و اخبار مربوط به بخش ویژه
    • آموزش ها و مقالات ویژه
    • ارزشمند ترین های اینترنت
  • انجمن پشتیبانی سایت
    • انجمن پرسش و پاسخ
    • درخواست آموزش / برنامه
  • برنامه نویسی با محصولات مایکروسافت
    • برنامه نویسی مبتنی بر Microsoft .Net Framework
    • Sharepoint
  • پایگاه های داده
    • SQL Server
    • NoSQL
    • سایر پایگاه‌های داده
  • Native Code
    • برنامه نویسی در Delphi
    • برنامه نویسی با C
    • برنامه نویسی در VB6
  • فناوری جاوا
  • زبان های اسکریپتی
  • برنامه نویسی میکروکنترلر (MicroController) ها و MicroProcessor ها
  • سیستم عامل ها
  • سورس کده
  • بخش راه اندازي وب سایت
  • انجمن تخصصی طراحی سایت
  • انجمن تخصصی بازاریابی و تبلیغات اینترنتی
  • انجمن تخصصی طراحی گرافیکی
  • گفت و گوی آزاد
  • دانلود انواع نرم افزار

دسته ها

  • دریافت آخرین نسخه اسکریپت
    • آپلود سنتر
    • مدیریت محتوا
  • دریافت آخرین نسخه قالب و استایل
    • قالب وردپرس

وبلاگ‌ها

چیزی برای نمایش وجود ندارد


جستجو در ...

نمایش نتایجی که شامل ...


تاریخ ایجاد

  • شروع

    پایان


آخرین بروزرسانی

  • شروع

    پایان


فیلتر بر اساس تعداد ...

تاریخ عضویت

  • شروع

    پایان


گروه


About Me

16 نتیجه پیدا شد

  1. لاصه! در گام اول این نگاشته خواهیم دید که چطور بزرگترین سایت فروشگاهی کشور هم می‌تواند نسبت به SQL Injection آسیب‌پذیر باشد و در گام دوم تکنیک و روش‌هایی که برای اکسپلویت کردن آسیب‌پذیری مورد استفاده قرار دادیم را ارائه می‌دهیم. داستان از کجا شروع شد؟ داستان از جایی شروع می‌شود که دیجی‌کلا برای روز چهارشنبه سوری آخر سال 97 و با هدف جذب مخاطب بیشتر، اقدام به برگزاری یک بازی آنلاین می‌کند. جوایزی که به برندگان این بازی اختصاص می‌یابند در تصویر زیر قابل مشاهده‌اند و برندگان بازی هم کسانی هستند که بتوانند بیشترین امتیاز را کسب کنند. و اما بازی چیست؟ بازی دقیقا مشابه دایناسورِ مرورگر کروم است، با این تفاوت که به جای تی‌رکس از یک کاراکتر موتور-سوار استفاده شده است بازی T-Rex, Run! کمی فنی‌تر به پیشنهاد یکی از دوستان به بررسی چند و چونِ عملکرد این بازی کنجکاو شدم و پس از یک دور بازی کردن که اتفاقا امتیاز پایینی هم کسب کردم، متوجه قسمتی در صفحه شدم که بیشترین امتیاز کسب شده تا کنون را نمایش می‌داد. طبیعتا اولین سوالی که برایم مطرح شد این بود که این امتیاز چطور به سرور ارسال و آنجا ذخیره می‌شود؟ به کمک نرم‌افزار Burp Suite به بررسی بسته‌های تبادلی پرداختم و اقدام به بازی مجدد کردم. همانطور که تصویر فوق مشخص است، 2 پارامتر جالب با نام‌های newscore و user_id در حال ارسال به سمت سرور هستند و در جواب آن‌ها، یک مقدار True بازگردانده می‌شود. با بررسی مختصر این پارامترها مشخص شد که: پارامتر user_id: نقش شناسه‌ی کاربر را بر عهده دارد و بنابراین می‌توانستم با تغییر مقدار آن امتیاز سایر کاربران را تغییر دهم (آسیب‌پذیری IDOR) پارامتر newscore: امتیاز پایان هر دوره بازی کردن کاربر را به صورت Base64 ارسال می‌کند و که از علامت تساوی (=) که در تصویر فوق Url Encode شده به مقدار 3D% است استفاده می‌کند. (به منظور Decode می‌توانید از Burp Suite Decoder یا از سرویس‌های آنلاین استفاده کنید) تا به اینجا ما یک آسیب‌پذیری پیدا کرده بودیم و آن هم تغییر امتیاز خود یا دیگر کاربران بود. اما آیا این تنها آسیب‌پذیری بود؟ خیر! برداشتی که از کد سمت سرور برای آپدیت کردن امتیاز کاربر در ذهنم داشتم، چنین بود: نمونه کد آسیب‌پذیری SQL injection با این برداشت، شروع به آزمودن سرور برای SQL Injection کردم؛ اما مشکلی وجود داشت. کدی که سمت سرور نوشته شده بود تنها یکی از دو پاسخ true یا null را باز‌می‌گرداند. اینجا بود که تلاش را برای پیدا کردن آسیب‌پذیری Blind Sql Injection یا تزریق پایگاه داده کورکورانه ادامه دادم. (به جهت حفظ محرمانگی، اطلاعاتی از پایگاه‌داده‌ی دیجی‌کالا نمی‌توانم ارائه دهم. بنابراین از اینجا به بعد با فرض این که پایگاه‌داده‌ی ما MySql است پیش می‌رویم) در مرحله‌ی بعد، برای بررسی آسیب‌پذیر بودن یا نبودن سرور، از تکنیک Time Based استفاده کردم. در این تکنیک با استفاده از دستورهای پایگاه داده ای مانند تابع ()Sleep می‌توان تشخیص داد که کوئری ارسال شده، سمت سرور اجرا می‌شود یا خیر. لیستی از این تکنیک ها در گیت هاب یاشار ، قرار دارند. مشکل بعدی؟ فرض کنیم که این آسیب‌پذیری وجود دارد. آیا اجرای دستور sleep روی بزرگترین وب‌سایت فروشگاهی کشور کار درستی‌ست؟ مسلما خیر! پس چه کنیم؟ مسئله‌ی دشواری شد! البته حتی اگر از روش sleep هم پیش می‌رفتیم باز چاره‌ی گره‌گشایی نبود! بیرون کشیدن اطلاعات از پایگاه‌داده با تکنیک‌های فوق حقیقتا زمان‌بر بود. خب، یک‌بار دیگر با هم مرور کنیم: آسیب‌پذیری ما از نوع Blind است و سرور تنها یک جواب True یا Null برمی‌گرداند. از تکنیک Time Based به جهت فضای مسئله نمی‌توانیم استفاده کنیم. برای حل این دو مشکل می‌توانیم از خودِ پارامتر امتیاز برای دریافت اطلاعات استفاده کنیم! اما منظورم چیست؟ منظور این است که به جای ارسال امتیاز به سمت سرور، یعنی مثلا به جای newscore = 1000، یک دستور به پایگاه‌داده ارسال کنیم و سپس خروجی آن دستور را بریم داخل پروفایل خود، که “بالاترین امتیاز” را نمایش می‌دهد مشاهده کنیم! از چه دستوری استفاده کنیم؟ newscore=user() تابع ()user در پایگاه‌داده‌ی MySql کاربر فعلی دیتابیس را بازمی‌گرداند. بنابراین تابع مذکور را base64encode می‌کنیم و ارسال می‌کنیم. مقادیر ارسالی پاسخی که دریافت کردیم: چه اتفاقی افتاد؟ مقادیر که درست بودند، پس چرا پاسخ True دریافت نکردیم؟ این مشکلات زمانی اتفاق میافته که برنامه‌نویس عزیز، نوع ذخیره‌سازی داده برای ستون newScore داخل دیتابیس را از نوع Integer تنظیم کرده باشد و به همین سبب اگر شما بخواهید یک رشته (مانند رشته‌ی “کاربر فعلی” دیتابیس) را در آن سلول ذخیره کنید، با خطا مواجه می‌شوید. اگر خواستید همین پایگاه‌داده را خودتان هم برای تست پیاده سازی کنید، می‌توانید پست Race Condition را مطالعه کنید و ببینید چطور می‌شود mysql را آماده و حمله‌ی جذاب Race Condition را شبیه سازی کرد. مشکل محدودیت فوق را چطور حل کنیم؟ از اونجایی که ما فقط می‌تونیم عدد را داخل سلول امتیاز قرار بدهیم، چرا نیاییم و اطلاعاتی که میخواهیم (نام کاربر دیتابیس) را تبدیل به عدد کنیم؟ برای این منظور می‌توان از تابع ()ascii داخل MySql که کد عددی یه کاراکتر (یه حرف از کلمه) را بازمی‌گرداند استفاده کرد. در اینجا چون ما اینجا یک کلمه مثل root@localhost داریم، باید از تابع دیگری به همراهش استفاده کنیم که ()substring نام دارد. این تابع 2 تا ورودی دریافت می‌کند و برای اینکه از یک مبدا تا یک مقصد از رشته‌ای که دریافت کرده‌است را استخراج کند، می‌توانیم بگوییم حرف به حرف خروجی دستور ()user را تبدیل به کد ()ascii کند و سپس خود را به آن مقادیر آپدیت کنیم. در نهایت هم هر بار برای هر کلمه آپدیت شد باید امتیاز خود را از کد ascii به “حرف(text)” تبدیل کنیم و با کنار قرار دادن خروجی، پاسخ تابع دلخواه‌مان رو مشاهده کنیم. در اسکریپت پایتون زیر، این مراحل را به صورت اتوماتیک انجام دادیم. داخل قسمت payload هر چیزی می‌تواند باشد و بستگی به دیتابیس دارد. مثلا waitfor و باید مقدار delay رو هم مشخص کنید. waitfor delay ’00:00:10′ نتیجه تا جایی که می‌توانستم سعی کردم مطالب را ساده بنویسم تا انتقال مطلب به راحتی انجام شود. امیدوارم این پست، بار آموزشی خوبی برای شما داشته باشد و در نهایت فراموش نکنید که همیشه باید بیرون از جعبه فکر کنید با وجود اینکه دیجی‌کالا هنوز پلن رسمی برای باگ بانتی ندارد، ولی bug-report راهکاری برای گزارش دادن باگ هاست.
  2. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي، مديريت مجوزها با استفاده از روال‌هاي ذخيره شده، نوشتن SQL پوياي امن، امضاي روال‌هاي ذخيره شده و جعل هويت در SQL Server، تخصيص مجوزهاي سطح ركورد و ايجاد نقش‌هاي برنامه كاربردي و فعالسازي دسترسي بين پايگاه داده‌ها پرداختيم. قسمت آخر از اين مجموعه مقالات به طور مختصر به امنيت SQL Server Expressمي‌پردازد. 2- امنيت SQL Server Express نسخه Microsoft SQL Server Express Edition (SQL Server Express)، مبتني بر Microsoft SQL Server است و اغلب ويژگي‌هاي اين موتور پايگاه داده را پشتيباني مي‌كند. اما SQL Server Express طوري طراحي شده است كه در آن، كليه ويژگي‌هاي غيرضروري و همچنين ارتباط شبكه به طور پيش‌فرض غيرفعال هستند. اين خصوصيت باعث مي‌شود كه سطح در دسترس براي حملات توسط كاربران خرابكار به طور قابل ملاحظه‌اي كاهش يابد. SQL Server Express معمولاً تحت عنوان يك نمونه نام گذاري شده (named instance) نصب مي‌گردد. نام پيش‌فرض اين نمونه SQlExpress است. يك نمونه نام گذاري شده (named instance) توسط نام شبكه كامپيوتر ميزبان آن نمونه به اضافه نام نمونه‌اي كه شما در طول نصب مشخص مي‌كنيد، شناسايي مي‌شود. 2-1- دسترسي شبكه در SQL Server Express به دلايل امنيتي پروتكل‌هاي شبكه به طور پيش فرض غيرفعال هستند. اين خصوصيت از حملات كاربران بيروني كه ممكن است كامپيوتر ميزبان نمونه SQL Server Express را مورد سوء استفاده و هدف حملات خود قرار دهند، جلوگيري مي‌كند. شما بايد به طور صريح ارتباط شبكه را فعال كرده و سرويس SQL Server Browser را نيز فعال نماييد تا بتوانيد از يك كامپيوتر ديگر به يك نمونه SQL Server Express متصل شويد. اما هنگامي‌كه ارتباط شبكه فعال مي‌گردد، يك نمونه SQL Server Express داراي الزامات امنيتي مشابه با ساير نسخه‌هاي SQL Server است. 2-2- نمونه‌هاي كاربري يك نمونه كاربري عبارت است از يك نمونه مجزاي موتور پايگاه داده SQL Server Express كه توسط يك نمونه والد SQL Server Express توليد شده است. هدف اوليه و اساسي يك نمونه كاربري اين است كه به كاربراني كه ويندوز را تحت يك حساب كاربري با حداقل دسترسي اجرا مي‌كنند، در سيستم محلي خود كاربر مجوز دسترسي مدير سيستم (sysadmin) را بر روي نمونه SQL Server Express بدهد. به عبارت ديگر مي‌توان گفت كه نمونه‌هاي كاربري مربوط به كاربراني كه بر روي سيستم‌هاي خود مدير سيستم هستند، نمي‌‎باشد. يك نمونه كاربري از يك نمونه اوليه SQL Server يا SQL Server Express و از طرف يك كاربر ايجاد مي‌شود. اين نمونه، يك پردازه كاربري را تحت بستر امنيتي ويندوز كاربر اجرا مي‌كند و نه به عنوان يك سرويس. در اين حالت لاگين‌هاي SQL Server غيرمجاز هستند و فقط لاگين‌هاي ويندوز پشتيباني مي‌شوند. اين مسأله از ايجاد تغييراتي خارج از مجوزهاي كاربر توسط نرم افزاري كه بر روي يك نمونه كاربري اجرا مي‌شود جلوگيري مي‌كند. يك نمونه كاربري همچنين به عنوان يك نمونه فرزند يا نمونه مشتري نيز شناخته مي‌شود و برخي اوقات نيز با استفاده از عبارت اختصاري RANU (run as normal user) به آن اشاره مي‌گردد. هر نمونه كاربري از نمونه والد خود و نيز از ساير نمونه‌هاي كاربري اجرا شده بر روي همان سيستم، كاملاً ايزوله است. پايگاه‌هاي داده نصب شده بر روي نمونه‌هاي كاربري فقط در مود تك كاربره (single-user) باز مي‌شوند و در نتيجه چندين كاربر به طور همزمان نمي‌توانند به آنها متصل شوند. پرس و جوهاي توزيع شده و نيز اتصال از راه دور براي نمونه‌هاي كاربري غيرفعال است. كاربران پس از اتصال به يك نمونه كاربري، داراي هيچ حق دسترسي ويژه‌اي بر روي نمونه SQL Server Express والد نيستند. منابع: http://msdn.microsoft.com/
  3. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي، مديريت مجوزها با استفاده از روال‌هاي ذخيره شده، نوشتن SQL پوياي امن، امضاي روال‌هاي ذخيره شده و جعل هويت در SQL Server و تخصيص مجوزهاي سطح ركورد و ايجاد نقش‌هاي برنامه كاربردي پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به فعالسازي دسترسي بين پايگاه‎‌هاي داده مي‌پردازد. 2- فعالسازي دسترسي بين پايگاه داده‌ها در SQL Server زنجيره مالكيت بين پايگاه‌هاي داده زماني اتفاق مي‌افتد كه يك روال در يك پايگاه داده به شيئي در يك پايگاه داده ديگر وابسته باشد. يك زنجيره مالكيت بين پايگاه‌هاي داده به همان روشي كار مي‌كند كه زنجيره مالكيت در يك پايگاه داده منفرد كار مي‌كند، به جز اينكه يك زنجيره مالكيت كه شكسته نشده باشد نياز دارد كه تمامي مالكان اشياء به حساب لاگين يكساني نگاشت گردند. درصورتي‌كه شيء منبع در پايگاه داده منبع و شيء مقصد در پايگاه داده مقصد توسط حساب لاگين يكساني مالكيت گردند، SQL Server مجوزهاي شيء مقصد را مورد بررسي قرار نمي‌دهد. 2-1- پيش‌فرض غيرفعال زنجيره مالكيت بين پايگاه‌هاي داده به طور پيش‌فرض غيرفعال است. مايكروسافت توصيه مي‌كند كه زنجيره مالكيت بين پايگاه‌هاي داده را غيرفعال نماييد، چرا كه شما را در برابر تهديدات امنيتي ذيل آسيب‌پذير مي‌سازد: مالكان پايگاه داده و اعضاي نقش‌هاي پايگاه داده db_ddladmin يا db_owners مي‌توانند اشيايي ايجاد كنند كه توسط ساير كاربران مالكيت مي‌شود. اين اشياء مي‌توانند به طور بالقوه اشياي پايگاه‌هاي داده ديگر را هدف قرار دهند. اين بدان معناست كه درصورتي‌كه شما زنجيره مالكيت بين پايگاه‌هاي داده را فعال نماييد بايد به اين كاربران در مورد داده‌هاي تمامي پايگاه‌هاي داده اعتماد داشته باشيد. كاربراني با مجوز CREATE DATABASE مي‌توانند پايگاه‌هاي داده جديدي ايجاد نمايند و آنها را به پايگاه‌هاي داده موجود متصل كنند. درصورتي‌كه زنجيره مالكيت بين پايگاه‌هاي داده فعال باشد، اين كاربران مي‌توانند از پايگاه‌هاي داده جديد به اشياي ساير پايگاه‌هاي داده كه مجوز آنها را در اختيار ندارند، دسترسي پيدا كنند. 2-2- فعال‌سازي زنجيره مالكيت بين پايگاه‌هاي داده زنجيره مالكيت بين پايگاه‌هاي داده بايد فقط در محيط‌هايي فعال گردد كه شما مي‌توانيد به طور كامل به كاربران داراي سطح دسترسي بالا اطمينان نماييد. اين مسأله مي‌تواند در طول تنظيمات و پيكربندي براي تمامي پايگاه‌هاي داده تنظيم گردد يا اينكه به طور انتخابي با استفاده از دستورات sp_configure و ALTER DATABASE درTransact-SQL براي يك پايگاه داده خاص تنظيم شود. براي تنظيم انتخابي زنجيره مالكيت بين پايگاه‌هاي داده، ابتدا از دستور sp_configure براي غيرفعال كردن آن براي سرور استفاده كنيد. سپس از دستور ALTER DATABASE به همراه SET DB_CHAINING ON براي تنظيم زنجيره مالكيت بين پايگاه‌هاي داده براي پايگاه‌هاي داده مورد نظر خود استفاده كنيد. مثال زير زنجيره مالكيت بين پايگاه‌هاي داده را براي تمامي پايگاه‌هاي داده فعال مي‌كند: EXECUTE sp_configure 'show advanced', 1; RECONFIGURE; EXECUTE sp_configure 'cross db ownership chaining', 1; RECONFIGURE; مثال زير زنجيره مالكيت بين پايگاه‌هاي داده را براي پايگاه‌هاي داده خاص Database1 و Database2 فعال مي‌كند: ALTER DATABASE Database1 SET DB_CHAINING ON; ALTER DATABASE Database2 SET DB_CHAINING ON; 2-3- SQL پويا زنجيره مالكيت بين پايگاه‌هاي داده در شرايطي كه دستورات SQL در حال اجرا به صورت پويا ايجاد شده باشند، كار نمي‌كند. مگر اينكه همان كاربر در هر دو پايگاه داده وجود داشته باشد. شما مي‌توانيد اين كار را در SQL Server با ايجاد يك روال ذخيره شده كه به داده‌هاي پايگاه داده ديگر دسترسي داشته باشد و امضاي آن روال با گواهينامه‌اي كه در هر دو پايگاه داده وجود داشته باشد انجام دهيد. اين كار، دسترسي به منابع پايگاه داده مورد استفاده روال را بدون نياز به تخصيص مجوز در اختيار كاربران قرار مي‌دهد.
  4. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي، مديريت مجوزها با استفاده از روال‌هاي ذخيره شده، نوشتن SQL پوياي امن و امضاي روال‌هاي ذخيره شده و جعل هويت در SQL Server پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به تخصيص مجوزهاي سطح ركورد و ايجاد نقش‌هاي برنامه كاربردي مي‌پردازد. 2- تخصيص مجوزهاي سطح ركورد در SQL Server در برخي سناريوها، نياز به كنترل دسترسي در سطح ريزتر و پايين‌تري وجود دارد. براي مثال، يك برنامه پايگاه داده بيمارستاني ممكن است اطلاعات تمامي بيماران را در يك جدول ذخيره كند. در عين حال ممكن است نياز باشد كه پزشكان فقط به مشاهده اطلاعات مربوط به بيمار خودشان محدود باشند. سناريوهاي مشابهي در محيط‌هاي مختلف از جمله برنامه‌هاي مالي، قانوني، دولتي و نظامي وجود دارند. البته SQL Server پياده‌سازي امنيت سطح ركورد را پشتيباني نمي‌كند. در نتيجه شما بايد ستون‌هاي اضافه‌اي در جداول خود ايجاد كنيد كه مكانيزم‌هاي فيلتر كردن ركوردها را تعريف نمايند. 2-1- پياده‌سازي مجوزهاي سطح ركورد مجوزهاي سطح ركورد براي برنامه‌هايي مورد استفاده قرار مي‌گيرند كه اطلاعات را در يك جدول ذخيره مي‌نمايند. هر ركورد داراي ستوني است كه پارامتري را تعريف مي‌كند كه بين ركوردهاي مختلف تفاوت ايجاد مي‌كند. اين پارامتر مي‌تواند كلمه كاربري، برچسب يا هر شناسه ديگري باشد. سپس شما روال‌هاي ذخيره شده پارامتري را ايجاد مي‌كنيد و مقادير مناسب را به آنها ارسال مي‌نماييد. كاربران مي‌توانند صرفاً ركوردهايي را مشاهده نمايند كه با مقدار مورد نظر تطابق داشته باشند. مراحل زير نحوه پيكربندي مجوزهاي سطح ركوردرا بر اساس نام كاربري يا نام لاگين شرح مي‌دهد: جدول را ايجاد كرده و ستون اضافه‌اي براي ذخيره كردن نام به آن بيفزاييد. View ي ايجاد كنيد كه داراي يك عبارت WHERE بر اساس ستون نام كاربر باشد. اين كار ركوردهاي بازگشت داده شده را به ركوردهايي كه اين ستون آنها داراي مقدار مورد نظر شماست محدود مي‌سازد. از يكي از توابع دروني براي مشخص كردن نام كاربري يا لاگين پايگاه داده استفاده كنيد. اين كار نياز به ايجاد view هاي مختلفي براي كاربران مختلف را از بين مي‌برد. نام شناسه لاگين كاربر را باز مي‌گرداند: WHERE UserName = SUSER_SNAME() USER_NAME يا CURRENT_USER، نام كاربر پايگاه داده را بازمي‌گرداند: WHERE UserName = CURRENT_USER() روال‌هاي ذخيره شده را براي انتخاب، افزودن، به روز رساني و حذف داده‌ها بر اساس view و نه بر اساس جداول پايه ايجاد كنيد. اين view فيلتري را فراهم مي‌كند كه ركوردهاي بازگشتي يا تغيير يافته را محدود مي‌سازد. براي روال‌هاي ذخيره شده‌اي كه داده‌ها را اضافه مي‌كنند، نام كاربري را با استفاده از همان تابع مشخص شده در عبارت WHERE به دست آورده و مقدار آن را به ستون UserName اضافه كنيد. تمامي مجوزها بر روي جداول و مشاهده‌ها را براي نقش عمومي ابطال نماييد. كاربران قادر نخواهند بود مجوزها را از ساير نقش‌هاي پايگاه داده به ارث ببرند، زيرا عبارت WHERE بر اساس نام‌هاي كاربري يا لاگين و نه بر اساس نقش‌ها ساخته شده است. مجوز EXECUTE را بر روي روال‌هاي ذخيره شده براي نقش‌هاي پايگاه داده تخصيص دهيد. كاربران فقط مي‌توانند از طريق روال‌هاي ذخيره شده ارائه شده به داده‌ها دسترسي پيدا كنند. 3- ايجاد نقش‌هاي برنامه كاربردي در SQL Server نقش‌هاي برنامه كاربردي راهي براي تخصيص مجوزها به يك برنامه كاربردي به جاي نقش يا كاربر پايگاه داده فراهم مي‌كنند. كاربران مي‌توانند به پايگاه داده وصل شوند، نقش برنامه كاربردي را فعال نمايند، و مجوزهاي تخصيص داده شده به برنامه كاربردي را دريافت نمايند. مجوزهاي تخصيص يافته به نقش برنامه كاربردي در طول مدت ارتباط اعمال مي‌شوند. نكته امنيتي نقش‌هاي برنامه كاربردي هنگامي فعال مي‌شوند كه يك برنامه كلاينت، يك نام نقش برنامه كاربردي و يك كلمه عبور را در رشته اتصال خود بگنجاند. از آنجاييكه كلمه عبور بايد بر روي سيستم كلاينت ذخيره گردد، يك آسيب‌پذيري امنيتي در برنامه كاربردي دو طرفه ايجاد مي‌شود. در يك برنامه سه طرفه، شما مي‌توانيد كلمه عبور را طوري ذخيره نماييد كه كاربران برنامه كاربردي به آن دسترسي نداشته باشند. 3-1- ويژگي‌هاي نقش برنامه كاربردي نقش‌هاي برنامه كاربردي داراي ويژگي‌هاي زير هستند: برخلاف نقش‌هاي پايگاه داده، نقش‌هاي برنامه كاربردي شامل هيچ عضوي نيستند. نقش‌هاي برنامه كاربردي زماني فعال مي‌شوند كه يك برنامه كاربردي، نام نقش برنامه كاربردي و يك كلمه عبور را براي روال ذخير شده سيستمي sp_setapprole تأمين نمايد. كلمه عبور بايدروي سيستم كلاينت ذخيره شده و در زمان اجرا ارائه گردد. يك نقش برنامه كاربردي نمي‌تواند از درون SQL Server فعال گردد. كلمه عبور رمز شده نيست. كلمه عبور پارامتر به صورت يك hash يك طرفه ذخيره مي‌گردد. زماني كه نقش برنامه كاربردي فعال مي‌شود، مجوزهاي بدست آمده از طريق نقش برنامه كاربردي در طول مدت اتصال باقي مي‌مانند. نقش برنامه كاربردي مجوزهاي تخصيص يافته به نقش عمومي را به ارث مي‌برد. اگر يك عضو نقش سروري ثابت sysadmin، يك نقش برنامه كاربردي را فعال كند، بستر امنيتي براي مدت اتصال به بستر نقش برنامه كاربردي تغيير مي‌يابد. اگر شما يك حساب مهمان در يك پايگاه داده ايجاد كنيد كه يك نقش برنامه كاربردي داشته باشد، نيازي به ايجاد يك حساب كاربر پايگاه داده براي نقش برنامه كاربردي يا براي هريك از لاگين‌هايي كه آن را خواسته‌اند نداريد. نقش‌هاي پايگاه داده فقط درصورتي مي‌توانند مستقيماً به پايگاه داده ديگري دسترسي يابند كه يك حساب مهمان در پايگاه داده دوم وجود داشته باشد. توابع دروني كه نام‌هاي لاگين را بازمي‌گردانند (مانند SYSTEM_USER)، نام لاگيني را كه نقش برنامه كاربردي را درخواست كرده است بازمي‌گردانند. توابع دروني كه نام‌هاي كاربر پايگاه داده را بازمي‌گردانند، نام نقش برنامه كابردي را بازمي‌گردانند. 3-2- اصل حداقل دسترسي نقش‌هاي برنامه كاربردي بايد فقط مجوزهاي مورد نياز را دريافت كنند. مجوزهاي نقش عمومي بايد در هر پايگاه داده‌اي كه از نقش برنامه كاربردي استفاده مي‌كند ابطال گردند. حساب مهمان را در هر پايگاه داده‌اي كه نمي‌خواهيد فراخوانندگان نقش برنامه كاربردي به آن دسترسي يابند، غير فعال نماييد. 3-3- بهبودهاي نقش برنامه كاربردي بستر اجرا مي‌تواند پس از فعال سازي يك نقش برنامه كاربردي به فراخواننده اصلي بازگردد تا نيازي به غيرفعال كردن connection pooling نباشد. روال sp_setapprole داراي گزينه جديدي است كه يك كوكي ايجاد مي‌كند كه شامل اطلاعات بستر در مورد فراخواننده است. شما مي‌توانيد با فراخواني روال sp_unsetapprole، نشست را بازگردانيد و كوكي را به آن ارسال نماييد. 3-4- جايگزين‌هاي نقش برنامه كاربردي نقش‌هاي برنامه كاربردي به امنيت كلمه عبور بستگي دارند كه يك آسيب‌پذيري امنيتي بالقوه را ايجاد مي‌كند. ممكن است كلمات عبور با جاسازي شدن در كد برنامه كاربردي يا ذخيره شدن بر روي ديسك افشا گردند. ممكن است شما مايل باشيد از روش‌هاي جايگزين ذيل استفاده نماييد: از تغيير بستر با عبارت EXECUTE AS به همراه عبارات NO REVERT و WITH COOKIE استفاده نماييد. شما مي‌توانيد يك حساب كاربري در پايگاه داده‌اي ايجاد كنيد كه به هيچ لاگيني نگاشت نشده است. سپس شما مجوزها را به اين حساب تخصيص مي‌دهيد. استفاده از EXECUTE AS با يك كاربر بدون لاگين امن‌تر است، چرا كه مبتني بر مجوز است نه مبتني بر كلمه عبور. روال‌هاي ذخيره شده را با گواهينامه‌ها امضا كنيد و صرفاً مجوز اجراي روال‌ها را صادر كنيد.
  5. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي، مديريت مجوزها با استفاده از روال‌هاي ذخيره شده و نوشتن SQL پوياي امن پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به امضاي روال‌هاي ذخيره شده و جعل هويت در SQL Server مي‌پردازد. 2- امضاي روال‌هاي ذخيره شده در SQL Server شما مي‌توانيد روال ذخيره شده را با استفاده از گواهينامه يا يك كليد غيرمتقارن امضاء نماييد. اين كار براي سناريوهايي طراحي شده است كه در آنها مجوزها نمي‌توانند از طريق زنجيره مالكيت به ارث برده شوند و يا اينكه زنجيره مالكيت در آنها پاره شده است (مانند SQL پويا). سپس مي‌توانيد يك كاربر منطبق بر آن گواهينامه ايجاد كنيد و مجوزهاي كاربري را براي شيئي كه روال ذخيره شده نياز به دسترسي به آن دارد، به آن گواهينامه تخصيص دهيد. هنگاميكه روال ذخيره شده اجرا مي‌گردد، SQL Server مجوزهاي كاربر گواهينامه را با مجوزهاي فراخواننده ادغام مي‌كند. بر خلاف عبارت EXECUTE AS، اين كار بستر اجراي روال را تغيير نمي‌دهد. توابع دروني كه نام لاگين و نام كاربري را بازمي‌گردانند، نام فراخواننده را بازمي‌گردانند نه نام كاربر گواهينامه را. امضاي ديجيتالي، يك داده رمز شده با كليد خصوصي امضا كننده است. اين كليد خصوصي اين اطمينان را ايجاد مي‌كند كه امضاي ديجيتالي منحصر به مالك آن است. شما مي‌توانيد روال‌هاي ذخيره شده، توابع يا تريگرها را امضا كنيد. توجه: شما مي‌توانيد يك گواهينامه در پايگاه داده اصلي ايجاد كنيد تا مجوزهاي سطح سرور را تخصيص دهيد. 2-1- ايجاد گواهينامه‌ها هنگاميكه يك روال ذخيره شده را با استفاده از گواهينامه امضاء مي‌كنيد، يك خلاصه داده شامل كد روال ذخيره شده بصورت درهم سازي شده و رمز شده با استفاده از كليد خصوصي ايجاد مي‌شود. اين خلاصه داده در زمان اجرا توسط كليد عمومي رمزگشايي مي‌شود و با مقدار درهم سازي شده روال ذخيره شده مقايسه مي‌گردد. اين كار از تغيير كد روال ذخيره شده توسط كسي كه به كليد خصوصي دسترسي ندارد جلوگيري مي‌كند. در نتيجه شما بايد اين روال را هر بار كه آن را تغيير مي‌دهيد، مجدداً امضا نماييد. چهار گام در امضاي يك ماژول وجود دارد كه به شرح زير است: ايجاد يك گواهينامه با استفاده از دستور CREATE CERTIFICATE [certificateName] در Transact-SQL. اين دستور چندين گزينه براي تنظيم تاريخ شروع و پايان و كلمه عبور دارد. تاريخ انقضاي پيش‌فرض يك سال است. ايجاد يك كاربر پايگاه داده مرتبط با اين گواهينامه با استفاده از دستور CREATE USER [userName] FROM CERTIFICATE [certificateName] در Transact-SQL. اين كاربر فقط در پايگاه داده وجود دارد و با هيچ لاگيني در ارتباط نيست. تخصيص مجوزهاي مورد نياز به كاربر گواهينامه بر روي اشياي پايگاه داده. توجه: گواهينامه نمي‌تواند مجوزها را به كاربري كه مجوزهاي وي توسط دستور DENY ابطال شده‌اند تخصيص دهد. دستور DENY همواره بر GRANT تقدم دارد و از ارث بردن مجوزهاي تخصيص داده شده به كاربر گواهينامه توسط فراخواننده جلوگيري مي‌كند. امضاي روال با گواهينامه با استفاده از دستور SIGNATURE TO [procedureName] BY CERTIFICATE [certificateName] در Transact-SQL. 3- تغيير مجوزها با استفاده از جعل هويت در SQL Server بسياري از برنامه‌ها براي دسترسي به داده‌ها، از روال‌هاي ذخيره شده با تكيه بر زنجيره مالكيت براي محدودسازي دسترسي به جداول پايه استفاده مي‌كنند. شما مي‌توانيد مجوزهاي EXECUTE را بر روي روال‌هاي ذخيره شده تخصيص دهيد و در عين حال مجوزهاي جداول پايه را رد كرده يا ابطال نماييد. SQL Server درصورتي‌كه روال ذخيره شده و جداول داراي مالك يكسان باشند، مجوزهاي فراخواننده را بررسي نمي‌كند. البته اگر اشياء داراي مالك‌هاي متفاوت باشند يا در مورد SQL پويا، زنجيره مالكيت كار نمي‌كند. شما مي‌توانيد هنگامي كه فراخواننده مجوزي بر روي اشياي مورد ارجاع ندارد، عبارت EXECUTE AS را در يك روال ذخيره شده مورد استفاده قرار دهيد. تأثير عبارت EXECUTE AS اين است كه بستر اجرا به كاربر پراكسي منتقل مي‌گردد. تمامي كد و تمامي فراخواني‌ها به روال‌هاي ذخيره شده تودرتو يا تريگرها، تحت بستر امنيتي كاربر پراكسي اجرا مي‌گردد. بستر اجرا فقط پس از اجراي روال يا هنگامي كه عبارت REVERT مورد استفاده قرار گيرد، به فراخواننده اصلي بازمي‌گردد. 3-1- تغيير بستر با استفاده از عبارت EXECUTE AS عبارت EXECUTE AS در Transact-SQL به شما اجازه مي‌دهد كه بستر اجراي يك دستور را با جعل هويت يك login يا يك كاربر ديگر پايگاه داده تغيير دهيد. اين يك تكنيك پيش‌فرض براي تست پرس و جوها و روال‌ها به عنوان يك كاربر ديگر است. EXECUTE AS LOGIN = 'loginName'; EXECUTE AS USER = 'userName'; شما بايد مجوزهاي IMPERSONATE را بر روي لاگين يا كاربري كه در حال جعل هويت وي هستيد داشته باشيد. اين مجوز براي sysadmin براي تمامي پايگاه‌هاي داده و براي اعضاي نقش db_owner در پايگاه‌هاي داده‌اي كه مالك آن هستند معنا دارد. 3-2- تخصيص مجوزها با استفاده از عبارت EXECUTE AS شما مي‌توانيد عبارت EXECUTE AS را در بخش هدر يك روال ذخيره شده، تريگر يا تابع تعريف شده توسط كاربر استفاده كنيد. اين عبارت باعث مي‌شود كه روال در بستر نام كاربر يا كلمه كليدي مشخص شده در عبارت EXECUTE AS اجرا گردد. شما مي‌توانيد يك كاربر پراكسي در پايگاه داده ايجاد كنيد كه به هيچ لاگيني نگاشت نشده باشد و صرفاً مجوزهاي لازم بر روي اشياي مورد دسترسي روال را به آن تخصيص دهيد. صرفاً كاربر پراكسي مشخص شده در عبارت EXECUTE AS بايد مجوزهايي بر روي تمامي اشياي مورد دسترسي ماژول را داشته باشد. توجه: برخي اعمال مانند TRUNCATE TABLE داراي مجوزهاي قابل تخصيص نيستند. 3-3- استفاده از EXECUTE AS به همراه REVERT شما مي‌توانيد از عبارت REVERT در Transact-SQL براي بازگشتن به بستر اصلي اجرا استفاده كنيد. عبارت اختياري WITH NO REVERT COOKIE = @variableName به شما اجازه مي‌دهد كه درصورت صحيح بودن مقدار متغير @variableName، بستر اجرا را به بستر فراخواننده بازگردانيد. اين به شما اجازه مي‌دهد كه بستر اجرا را در محيط‌هايي كه connection pooling مورد استفاده قرار مي‌گيرد، به بستر فراخواننده بازگردانيد. از آنجايي كه مقدار @variableName صرفاً براي فراخواننده عبارت EXECUTE AS شناخته شده است، فراخواننده مي‌تواند تضمين نمايد كه بستر اجرا نمي‌تواند توسط كاربر نهايي كه برنامه را اجرا مي‌كند تغيير يابد. هنگامي كه اين ارتباط بسته مي‌شود، به pool بازگردانده مي‌شود. 3-4- مشخص كردن بستر اجرا شما علاوه بر مشخص كردن يك كاربر، مي‌توانيد EXECUTE AS را با هريك از كلمات كليدي زير مورد استفاده قرار دهيد: CALLER. پيش‌فرض، اجرا به عنوان CALLER است. اگر گزينه ديگري مشخص نشده باشد، روال در بستر امنيتي فراخواننده اجرا مي‌شود. OWNER. اجرا به عنوان OWNER، روال را در بستر مالك روال اجرا مي‌كند. درصورتي‌كه روال در يك schema كه مالك آن dbo يا مالك پايگاه داده است اجرا شود، اين روال با مجوزهاي بدون محدوديت اجرا مي‌گردد. SELF. اجرا به عنوان SELF، روال را در بستر امنيتي ايجاد كننده روال ذخيره شده اجرا مي‌كند. اين مسأله معادل اجرا به عنوان يك كاربر خاص است كه در آن، كاربر خاص همان فرد ايجاد كننده روال باشد.
  6. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR، سناريوهاي امنيت برنامه كاربردي و مديريت مجوزها با استفاده از روال‌هاي ذخيره شده پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به نوشتن SQL پوياي امن در SQL Server مي‌پردازد. 2- نوشتن SQL پوياي امن در SQL Server تزريق SQL پروسه‌اي است كه در آن يك كاربر خرابكار، دستورات Transact-SQL را به جاي ورودي معتبر وارد مي‌كند. اگر ورودي مستقيماً و بدون اعتبارسنجي به سرور ارسال گردد و اگر برنامه به طور ناآگاهانه كد تزريق شده را اجرا نمايد، اين حمله پتانسيل آسيب زدن يا تخريب داده‌ها را دارا خواهد بود. هر روالي كه دستورات SQL را مي‌سازد بايد از جهت آسيب‌پذيري‌هاي تزريق SQL مورد بازبيني قرار گيرد، چرا كه SQL Server تمامي پرس و جوهايي را كه از نظر قواعد زباني صحيح و معتبر هستند اجرا خواهد كرد. حتي داده‌هاي پارامتري شده مي‌توانند توسط يك مهاجم متخصص و مصمم دستكاري گردند. درصورتي‌كه شما از SQL پويا استفاده مي‌كنيد، اطمينان حاصل كنيد كه دستورات خود را پارامتري كرده باشيد و هرگز مقادير پارامتري را مستقيماً در رشته پرس و جو قرار ندهيد. 2-1- آناتومي يك حمله تزريق SQL پروسه تزريق SQL با خروج ناگهاني يك رشته متني و الحاق يك دستور جديد كار مي‌كند. از آنجايي كه ممكن است رشته‌هاي ديگري پيش از اجرا به دستور الحاق شده باشد، فرد تبهكار رشته تزريق شده را با يك نشانه دستور «--» به پايان مي‌رساند. متن الحاقي در زمان اجرا ناديده گرفته مي‌شود. با استفاده از يك علامت نقطه ويرگول چندين دستور مي‌توانند به طور همزمان تزريق گردند. تا زماني كه كد SQL تزريق شده به لحاظ دستوري صحيح باشد، فعاليت موذيانه مهاجم از ديد برنامه قابل تشخيص نخواهد بود. در نتيجه شما بايد تمامي ورودي‌هاي كاربر را اعتبارسنجي كرده و كدي را كه دستورات SQL ساخته شده را در سرور اجرا مي‌كند، به دقت مورد بازبيني قرار دهيد. هرگز ورودي كاربر را كه اعتبارسنجي نشده است به رشته دستور SQL متصل نكنيد. اتصال رشته‌ها نقطه اوليه تزريق SQL است. در ادامه به چند راهكار مفيد اشاره مي‌كنيم: هرگز دستورات Transact-SQL را مستقيماً از ورودي كاربر نسازيد؛ از روال‌هاي ذخيره شده براي اعتبارسنجي ورودي كاربر استفاده كنيد. ورودي كاربر را با بررسي نوع، طول، فرمت و محدوده آن اعتبارسنجي نماييد. از تابع QUOTENAME() براي خلاصي از نام‌هاي سيستم يا از تابع REPLACE() براي خلاصي از هر كاراكتري در رشته استفاده كنيد. چندين لايه اعتبارسنجي در هر بخش برنامه خود قرار دهيد. اندازه و نوع داده‌اي ورودي را بررسي كنيد و محدوديت‌هاي لازم را اعمال نماييد. اين كار مي‌تواند به جلوگيري از سرريز بافر تعمدي كمك كند. محتويات متغيرهاي رشته‌اي را بررسي كرده و فقط مقادير مورد قبول را بپذيريد. از پذيرش ورودي‌هاي حاوي داده‌هاي باينري، فاصله‌هاي متوالي و كاراكترهاي كامنت خودداري كنيد. هنگاميكه با اسناد XML كار مي‌كنيد، تمامي داده‌ها را در مورد schema ي آن اعتبارسنجي كنيد. در محيط‌هاي چندبخشي، تمامي داده‌ها بايد پيش از پذيرش در محدوده مورد اعتماد، اعتبارسنجي گردند. رشته‌هاي زير را در فيلدهايي كه نام فايل‌ها از آن ساخته مي‌شود نپذيريد: AUX، CLOCK$، COM1 تا COM8، CON، CONFIG$، LPT1 تا LPT8، NUL و PRN. از شيء SqlParameter به همراه روال‌هاي ذخيره شده و دستورات براي بررسي و اعتبارسنجي نوع و طول استفاده كنيد. از عبارات Regex در كد سمت كلاينت براي فيلتر كردن ورودي‌هاي نامعتبر استفاده كنيد. 2-2- استراتژي‌هاي SQL پويا اجراي دستورات SQL كه به شكل پويا توليد شده‌اند در كد روالي شما، زنجيره مالكيت را پاره مي‌كند و باعث مي‌شود كه SQL Server مجوزهاي فراخواننده را در مورد اشيايي كه از طريق SQL پويا مورد دسترسي قرار مي‌گيرند، بررسي نمايد. SQL Server متدهايي براي تخصيص دسترسي كاربران به داده‌ها با استفاده از روال‌هاي ذخيره شده و توابع تعريف شده توسط كاربر دارد كه SQL پويا را اجرا مي‌كند. استفاده از جعل هويت با عبارت EXECUTE AS در زبان Transact-SQL امضاي روال‌هاي ذخيره شده با گواهينامه‌ها هر دو مورد فوق به صورت مفصل در قسمت‌هاي آينده اين مجموعه مقالات توضيح داده خواهند شد. اكنون به شرح مختصر هريك مي‎‌پردازيم. 2-2-1- EXECUTE AS عبارت EXECUTE AS مجوزهاي فراخواننده را با مجوزهاي كاربري كه در عبارت EXECUTE AS مشخص شده است جايگزين مي‌كند. روال‌هاي ذخيره شده تو در تو يا تريگرها، تحت مفاد امنيتي كاربر پراكسي اجرا مي‌گردند. اين مسأله مي‌تواند برنامه‌هايي را كه به امنيت سطح ركورد تكيه دارند يا نياز به مميزي دارند، دچار اختلال نمايد. برخي توابع كه هويت كاربر را بازمي‌گردانند، كاربر مشخص شده در EXECUTE AS را بازمي‌گردانند نه فراخواننده اصلي را. نتيجه اجرا فقط پس از اجراي روال يا هنگامي‌كه عبارت REVERT مورد استفاده قرار گيرد، به فراخواننده اصلي بازمي‌گردد. 2-2-2- امضاي گواهينامه هنگامي‌كه يك روال ذخيره شده كه توسط يك گواهينامه امضاء شده اجرا مي‌گردد، مجوزهاي تخصيص داده شده به كاربر گواهينامه با مجوزهاي فراخواننده ادغام مي‌شوند. محيط اجرا يكسان باقي مي‌ماند و كاربر گواهينامه هويت فراخواننده را به خود اختصاص نمي‌دهد. امضاي روال‌هاي ذخيره شده نيازمند پياده‌سازي گام‌هاي مختلفي است. هر بار كه روال تغيير مي‌يابد، بايد مجدداً امضاء گردد. 2-2-3- دسترسي بين پايگاه‌هاي داده زنجيره‌هاي مالكيت بين پايگاه‌هاي داده در شرايطي كه دستورات SQL به صورت پويا ساخته شده‌اند كار نمي‌كنند. شما مي‌توانيد اين مسأله را بدين صورت در SQL Server حل نماييد كه يك روال ذخيره شده كه به داده‌هاي پايگاه داده ديگر دسترسي دارد ايجاد كنيد و سپس آن روال را توسط يك گواهينامه كه در هر دو پايگاه داده وجود دارد امضاء نماييد. اين كار امكان دسترسي به منابع پايگاه داده مورد استفاده توسط روال را بدون تخصيص دسترسي يا مجوزهاي پايگاه داده، در اختيار كاربر قرار مي‌دهد. منابع: http://msdn.microsoft.com/en-us/library/bb669074%28v=vs.110%29.aspx
  7. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، رمزگذاري داده‌ها و امنيت يكپارچه CLR و سناريوهاي امنيت برنامه كاربردي پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به مديريت مجوزها با استفاده از روال‌هاي ذخيره شده در SQL Server مي‌پردازد. 2- مديريت مجوزها با استفاده از روال‌هاي ذخيره شده در SQL Server يك روش ايجاد چندين خط دفاعي در اطراف پايگاه داده شما اين است كه تمامي دسترسي‌هاي داده‌ها را با استفاده از روال‌هاي ذخيره شده (stored procedures) يا توابع تعريف شده توسط كاربر پياده‌سازي نماييد. در اين روش، شما تمامي مجوزها به اشياي لايه زيرين مانند جداول را لغو مي‌كنيد و مجوزهاي اجرا را به روال‌هاي ذخيره شده تخصيص مي‌دهيد. اين كار به شكل مؤثري يك محوطه دفاعي در اطراف داده‌ها و اشياي پايگاه داده شما ايجاد مي‌كند. 2-1- مزاياي روال ذخيره شده روال‌هاي ذخيره شده از مزاياي زير بهره‌مند هستند: منطق داده‌ها و قوانين كسب و كار مي‌توانند طوري اعمال گردند كه كاربران بتوانند فقط به روش‌هايي كه توسعه دهندگان و مديران پايگاه داده مي‌خواهند، به داده‌ها و اشياء دسترسي پيدا كنند. روال‌هاي ذخيره شده پارامتري كه تمامي ورودي‌هاي كاربر را اعتبارسنجي مي‌كنند مي‌توانند براي خنثي كردن حملات تزريق SQL مورد استفاده قرار گيرند. درصورتي‌كه شما از SQL دايناميك استفاده نماييد، بايد اطمينان حاصل كنيد كه دستورات خود را پارامتري كرده‌ايد و هرگز مقادير پارامترها را به طور مستقيم در يك رشته پرس و جو قرار نمي‌دهيد. پرس و جوهاي اقتضايي و موردي و دستكاري‌هاي داده‌ها مي‌توانند غيرمجاز گردند. اين كار از تخريب عمدي يا ناآگاهانه داده‌ها توسط كاربران يا اجراي پرس و جوهايي كه كارآيي و بازدهي سرور يا شبكه را تحت تأثير قرار مي‌دهند جلوگيري مي‌كند. خطاها مي‌توانند بدون ارسال مستقيم به برنامه‌هاي كلاينت، در كد روال مديريت گردند. اين كار از بازگرداندن پيغام‌هاي خطا كه مي‌تواند به حملات پويش (probing) كمك كند، جلوگيري مي‌نمايد. لاگ خطاها و مديريت آنها را بر روي سرور انجام دهيد. روال‌هاي ذخيره شده مي‌توانند يك‌بار نوشته شده و توسط برنامه‌هاي متعدد مورد دسترسي قرار گيرند. برنامه‌هاي كلاينت نيازي به دانستن هيچ چيز درباره ساختارهاي داده‌هاي زيرين ندارند. تا زماني كه تغييرات بر روي فهرست پارامترها يا انواع داده‌هاي بازگردانده شده تأثير نگذارند، كد روال ذخيره شده مي‌تواند بدون نياز به تغيير در برنامه‌هاي كلاينت تغيير يابد. روال‌هاي ذخيره شده مي‌توانند با تركيب چندين عمليات در يك فراخواني روال، ترافيك شبكه را كاهش دهند. 2-2- اجراي روال ذخيره شده روال‌هاي ذخيره شده از مزيت زنجيره مالكيت (ownership chaining) براي فراهم كردن دسترسي به داده‌ها برخوردارند، به اين ترتيب كاربران نيازي به داشتن مجوز صريح براي دسترسي به اشياي پايگاه داده ندارند. زنجيره مالكيت زماني ايجاد مي‌شود كه مالك اشيايي كه به صورت متوالي و پي در پي به يكديگر دسترسي دارند، يك كاربر باشد. براي مثال، يك روال ذخيره شده مي‌تواند ساير روال‌هاي ذخيره شده را فراخواني كند يا اينكه يك روال ذخيره شده مي‌تواند به چندين جدول دسترسي پيدا كند. درصورتي‌كه تمامي اشياي موجود در زنجيره اجرا داراي يك مالك يكسان باشند، SQL Server فقط مجوز اجرا را براي فراخواننده چك مي‌كند، اما مجوزهاي فراخواننده را براي ساير اشياء چك نمي‌كند. در نتيجه شما فقط كافي است كه مجوزهاي اجرا را به روال‌هاي ذخيره شده تخصيص دهيد و مي‌توانيد تمامي مجوزها را براي جداول زيرين ابطال يا لغو نماييد. 2-3- تجربيات فقط نوشتن روال‌هاي ذخيره شده براي امن‌سازي برنامه كافي نيست. شما بايد همچنين حفره‌هاي امنيتي بالقوه زير را نيز در نظر بگيريد: مجوزهاي اجرا را بر روي روال‌هاي ذخيره شده براي آن دسته از نقش‌هاي پايگاه داده كه مايليد قادر به دسترسي به داده‌ها باشند، تخصيص دهيد. تمامي مجوزها به جداول لايه زيرين براي تمامي نقش‌ها و كاربران در پايگاه داده از جمله نقش عمومي را ابطال يا لغو نماييد. تمامي كاربران مجوزها را از نقش عمومي به ارث مي‌برند. بنابراين ابطال مجوزها براي نقش عمومي به اين معناست كه صرفاً مالكان و اعضاي sysadmin داراي دسترسي هستند و هيچ يك از كاربران ديگر قادر به ارث بردن اين مجوزها ار نقش‌هاي ديگر نخواهند بود. كاربران يا نقش‌ها را به نقش‌هاي sysadmin يا db_owner اضافه نكنيد. مديران سيستم و مالكان پايگاه داده مي‌توانند به تمامي اشياي پايگاه داده دسترسي پيدا كنند. حساب كاربري مهمان را غيرفعال نماييد. اين كار از اتصال كاربران ناشناس به پايگاه داده جلوگيري مي‌كند. در پايگاه‌هاي داده جديد حساب كاربري مهمان به‌طور پيش‌فرض غيرفعال است. مديريت خطا و لاگ برداري از خطاها را پياده‌سازي كنيد. روال‌هاي ذخيره شده پارامتري ايجاد كنيد كه تمامي ورودي‌هاي كاربر را اعتبارسنجي مي‌كنند. تمامي ورودي‌هاي كاربر را غير قابل اعتماد در نظر بگيريد. از SQL دايناميك مگر در مواقع لزوم دوري كنيد. از تابع Transact-SQL QUOTENAME() براي محدودسازي يك مقدار رشته‌اي استفاده كنيد و از وقوع هر جداكننده‌اي (delimiter) در رشته ورودي جلوگيري كنيد.
  8. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، تفويض اختيار و مجوزها در SQL Server، و رمزگذاري داده‌ها و امنيت يكپارچه CLR پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به سناريوهاي امنيت برنامه كاربردي در SQL Server مي‌پردازد. 2- سناريوهاي امنيت برنامه كاربردي در SQL Server هيچ راه صحيح يكتايي براي ايجاد يك برنامه كلاينت امن SQL Server وجود ندارد. هر برنامه از نقطه نظر ملزومات، محيط به كارگيري و جمعيت كاربران منحصر به فرد است. ممكن است برنامه‌اي كه در ابتداي به كار گيري منطقاً امن است، در گذر زمان از امنيت آن كاسته شود. چرا كه پيش‌بيني تهديداتي كه در آينده ظاهر خواهند شد با هر دقتي غيرممكن است. براي SQL Server به عنوان يك محصول، نسخه‌هاي زيادي عرضه شده است تا جديدترين ويژگي‌هاي امنيتي را كه توسعه دهندگان را قادر به ساخت برنامه‌هاي امن پايگاه داده مي‌كند، در خود جاي دهد. البته امنيت در يك جعبه قرار نمي‌گيرد، بلكه نياز به كنترل و به‌روز رساني مداوم دارد. 2-1- تهديدات معمول توسعه دهندگان نياز دارند تهديدات امنيتي، ابزارهاي ارائه شده براي مقابله با آنها، و نحوه جلوگيري از حفره‌هاي امنيتي كه توسط خودشان ايجاد مي‌شود را درك كنند. امنيت مي‌تواند به عنوان يك زنجير در نظر گرفته شود كه شكستگي هريك از حلقه‌هاي آن، استحكام كل زنجير را كاهش مي‌دهد. فهرست زير شامل برخي تهديدات امنيتي معمول است كه جزئيات و نحوه مقابله با هريك مورد بررسي قرار مي‌گيرد. 2-1-1- تزريق SQL تزريق SQL روالي است كه طي آن، كاربر خرابكار دستورات Transact-SQL را به جاي ورودي معتبر وارد مي‌نمايد. درصورتي‌كه اين ورودي به طور مستقيم و بدون اعتبارسنجي به سرور ارسال گردد و درصورتي‌كه سرور به‌صورت ناآگاهانه و غيرعمدي اين كد تزريق شده را اجرا نمايد، آنگاه اين حمله پتانسيل تخريب يا آسيب زدن به داده‌ها را داراست. شما مي‌توانيد حملات تزريق SQL به سرور را با استفاده از روال‌هاي ذخيره شده و دستورات پارامتري، اجتناب از SQL دايناميك و محدودسازي مجوزها براي تمامي كاربران، خنثي نماييد. 2-1-2- افزايش امتياز حق دسترسي حملات افزايش امتياز حق دسترسي زماني اتفاق مي‌افتند كه يك كاربر قادر باشد امتيازات و حقوق دسترسي يك حساب كاربري قابل اعتماد (trusted) مانند مالك پايگاه داده يا administrator را به خود تحصيص دهد. همواره حساب‌هاي كاربري را با حداقل حق دسترسي ايجاد كنيد و صرفاً مجوزهاي مورد نياز را به هر كاربر تخصيص دهيد. اين كار درصورت وقوع حمله، حجم خرابي را محدود مي‌كند. در هنگام انجام فعاليت‌هايي كه نياز به مجوزهاي بيشتري دارند، فقط در طول مدت انجام آن فعاليت از ثبت روال (procedure signing) يا تغيير هويت (impersonation) استفاده كنيد. شما مي‌توانيد روال‌ها را توسط گواهينامه‌ها ثبت كرده يا از تغيير هويت براي تخصيص موقتي مجوزها استفاده نماييد. 2-1-3- پويش كردن و مشاهده هوشمند يك حمله پويش (probing) مي‌تواند از پيغام‌هاي خطاي توليد شده توسط برنامه براي جستجوي آسيب‌پذيري‌هاي امنيتي استفاده كند. مديريت خطا را در تمامي كد خود پياده‌سازي نماييد تا بدين وسيله از بازگرداندن اطلاعات خطاي SQL Server به كاربر نهايي جلوگيري كنيد. 2-1-4- احراز هويت يك حمله تزريق رشته اتصال به پايگاه داده مي‌تواند هنگام استفاده از login هاي SQL Server اتفاق بيفتد، به شرطيكه يك رشته اتصال مبتني بر ورودي كاربر در زمان اجرا ساخته شود. درصورتي‌كه اين رشته اتصال در مورد زوج‌هاي كلمات كليدي معتبر چك نشود، مهاجم مي‌تواند كاراكترهاي اضافي را وارد كند و به طور بالقوه به داده‌هاي حساس يا ساير منابع سرور دسترسي پيدا كند. هرجا كه ممكن است از احراز هويت ويندوز استفاده كنيد. درصورتي‌كه مجبور هستيد از login هاي SQL Server استفاده كنيد، از SqlConnectionStringBuilder براي ساخت و اعتبارسنجي رشته‌هاي اتصال در زمان اجرا استفاده نماييد. 2-1-5- كلمات عبور علت موفقيت بسياري از حملات اين است كه يك فرد نقوذگر قادر بوده است كلمه عبور يك كاربر داراي امتياز و حق دسترسي بالاتر را به دست آورد يا حدس بزند. كلمات عبور اولين خط دفاعي شما در مقابل نفوذگرها است، بنابراين استفاده از كلمات عبور قوي و مستحكم براي امنيت سيستم شما حياتي است. سياست‌هاي كلمه عبور را براي احراز هويت مود تركيبي ايجاد كرده و استفاده از آن را الزام نماييد. همواره و حتي هنگامي كه از احراز هويت ويندوز استفاده مي‌كنيد، يك كلمه عبور قوي و مستحكم به حساب كاربري sa تخصيص دهيد.
  9. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server، انواع سناريوهاي احراز هويت در SQL Server، و تفويض اختيار و مجوزها در SQL Server پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به توضيح رمز گذاري داده‌ها و امنيت يكپارچه CLR در SQL Server مي‌پردازد. 2- رمزگذاري داده‌ها در SQL Server SQL Server توابعي را براي رمزگذاري و رمزگشايي داده‌ها با استفاده از يك كليد نامتقارن يا يك كليد متقارن، فراهم مي‌آورد. SQL Server تمامي اين فعاليت‌ها را در يك محل ذخيره‌سازي (حافظه) دروني گواهينامه مديريت مي‌كند. اين حافظه از يك سلسله مراتب رمزگذاري استفاده مي‌كند كه گواهينامه‌ها و كليدها را در يك سطح با لايه‌اي بر روي آن در اين سلسله مراتب، امن‌سازي مي‌كند. اين محدوده SQL Server تحت عنوان حافظه محرمانه (Secret Storage) شناخته مي‌شود. سريع‌ترين مود رمزگذاري پشتيباني شده توسط توابع رمزگذاري، رمزگذاري با استفاده از كليدهاي متقارن است. اين مود رمزگذاري براي مديريت حجم زيادي از داده‌ها مفيد بوده و مورد استفاده قرار مي‌گيرد. كليدهاي متقارن رمزگذاري مي‌توانند توسط گواهينامه‌ها، كلمات عبور يا ساير كليدهاي متقارن رمزگشايي شوند. 2-1- كليدها و الگوريتم‌ها SQL Server چندين الگوريتم متفاوت رمزگذاري با استفاده از كليد متقارن را پشتيباني مي‌كند. از جمله اين الگوريتم‌هاي كليد متقارن مي‌توان به DES، Triple DES، RC2، RC4، 128-bit RC4، 128-bit AES و 256-bit AES اشاره كرد. قابل ذكر است كه تمامي الگوريتم‌هاي مذكور با استفاده از Windows Crypto API پياده‌سازي مي‌شوند. SQL Server در داخل قلمرو يك ارتباط پايگاه داده مي‌تواند چندين كليد متقارن باز را نگهداري كند. يك كليد باز از حافظه بازيابي مي‌گردد و براي رمزگشايي داده‌ها در دسترس قرار مي‌گيرد. زماني كه داده‌اي رمزگشايي مي‌شود، نيازي نيست كه كليد متقارن مورد استفاده براي اين رمزگشايي مشخص گردد. چرا كه هر داده رمز شده شامل يك شناسه كليد (key GUID) مربوط به كليد مورد استفاده براي رمز كردن همان داده مي‌باشد. درصورتي‌كه كليد صحيح رمزگشايي شده و باز باشد، موتور SQL Server جريان بايت رمز شده را با اين كليد متقارن باز تطبيق مي‌دهد. سپس اين كليد براي انجام عمليات رمزگشايي مورد استفاده قرار گرفته و داده‌هاي رمزگشايي شده را باز مي‌گرداند. اما درصورتي‌كه كليد صحيح باز نباشد، مقدار NULL بازگردانده مي‌شود. 3- امنيت يكپارچه CLR در SQL Server Microsoft SQL Server، يكپارچه‌سازي جزء CLR فريم ورك .NET را فراهم مي‌آورد. يكپارچه‌سازي CLR به شما اجازه مي‌دهد كه روال‌هاي ذخيره شده، تريگرها، انواع (type ها) تعريف شده توسط كاربر، توابع تعريف شده توسط كاربر، توابع تجميعي (aggregate ها) تعريف شده توسط كاربر، و توابع streaming table-valued را با استفاده از هر زبان فريم ورك .NET مانند Microsoft Visual Basic .NET يا Microsoft Visual C#، بنويسيد. CLR يك مدل امنيتي به نام مدل امنيتي دسترسي كد (CAS) را براي كدهاي مديريت شده پشتيباني مي‌نمايد. در اين مدل، مجوزها بر اساس شواهد تأمين شده توسط كد در متاديتا به assembly ها تخصيص مي‌يابند. SQL Server، مدل امنيتي مبتني بر كاربر SQL Server را با مدل امنيتي مبتني بر دسترسي كد CLR مجتمع مي‌سازد.
  10. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server و انواع سناريوهاي احراز هويت در SQL Server پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به توضيح تفويض اختيار و مجوزها در SQL Server مي‌پردازد. 2- تفويض اختيار و مجوزها در SQL Server هنگامي كه شما اشياي پايگاه داده را ايجاد مي كنيد، بايد به طور صريح مجوزها را اعطا نماييد تا آنها را براي كاربران قابل دسترسي سازيد. هر شيء قابل امن سازي مجوزهايي دارد كه مي تواند با استفاده از دستورات مجوز، به يك كاربر اختصاص يابد. 2-1- اصل حداقل دسترسي روش توسعه يك برنامه با استفاده از يك حساب كاربري با حداقل مجوز (LUA)، بخشي مهم از يك استراتژي دقاع در عمق براي مقابله با تهديدات امنيتي است. روش LUA اين اطمينان را ايجاد مي كند كه كابران از اصل حداقل دسترسي پيروي مي كنند و هميشه با حساب هاي كاربري محدود وارد مي شوند. وظايف مديريتي با استفاده از نقش هاي ثابت سرور انجام مي شوند، و استفاده از نقش ثابت سروري sysadmin به طور جدي محدود است. همواره از اصل حداقل دسترسي در هنگام اعطاي مجوزها به كاربران پايگاه داده پيروي كنيد. حداقل مجوزهاي لازم براي انجام وظايف را به يك كاربر يا نقش اعطا نماييد. 2-2- مجوزهاي مبتني بر نقش تخصيص مجوزها به نقش‌ها به جاي كاربران، مديريت امنيت را ساده‌تر مي‌سازد. مجموعه مجوزهايي كه به يك نقش تخصيص مي‌يابند، توسط تمامي اعضاي آن نقش به ارث برده مي‌شوند. افزودن يا حذف كابران از يك نقش، ساده‌تر از ايجاد مجموعه مجوزهاي مجزا براي تك تك كاربران است. نقش‌ها مي‌توانند به‌صورت تودرتو تخصيص يابند، اما زياد بودن تعداد اين سطوح مي‌تواند بازدهي را كاهش دهد. شما همچنين مي‌توانيد كاربران را به نقش‌هاي ثابت پايگاه داده اضافه كنيد تا تخصيص مجوزها را ساده‌تر نماييد. شما مي‌توانيد مجوزها را در سطح schema تخصيص دهيد. كاربران به طور خودكار مجوزها را براي تمامي اشياي جديد ايجاد شده در آن schema دريافت مي‌كنند و نيازي به تخصيص مجوزها براي اشيايي كه جديداً ايجاد شده‌اند نخواهيد داشت. 2-3- مجوزها در كد procedural محفوظ ساختن دسترسي داده‌ها از طريق ماژول‌هايي مانند روال‌هاي ذخيره شده و توابع تعريف شده توسط كاربر، يك لايه محافظتي اضافه براي برنامه شما ايجاد مي‌كند. شما مي‌توانيد با تخصيص مجوزها فقط به روال‌هاي ذخيره شده و توابع و رد كردن مجوز به اشيايي مانند جداول، از تعامل مستقيم كاربران با اشياي پايگاه داده جلوگيري كنيد. SQL Server اين كار را با استفاده از زنجيره مالكيت انجام مي‌دهد. 2-4- دستورات مجوز سه دستور مجوز Transact-SQL در زير شرح داده شده‌اند: دستور مجوز شرح GRANT يك مجوز را تخصيص مي‌دهد. REVOKE يك مجوز را لغو مي‌كند. اين وضعيت پيش‌فرض يك شيء جديد است. زماني كه مجوزي براي يك كاربر يا يك نقش ابطال مي‌شود، آن كاربر يا نقش همچنان مي‌تواند آن مجوز را از ساير گروه‌ها يا نقش‌هايي كه عضو آن است به ارث ببرد. DENY DENY يك مجوز را به شكلي ابطال مي‌كند كه آن مجوز قابل به ارث بردن نيز نباشد. DENY بر تمامي مجوزها اولويت دارد و البته به جز اينكه بر مالكان اشياء يا اعضاي sysadmin اعمال نمي‌گردد. اگر شما مجوزهاي يك شيء را براي نقش عمومي DENY كنيد، اين مجوز براي تمامي كاربران و نقش‌ها به جز مالكان اشياء و اعضاي sysadmin لغو مي‌گردد. دستور GRANT مي‌تواند مجوزها را به گروه يا نقشي تخصيص دهد كه مي‌تواند توسط كاربران پايگاه داده به ارث برده شود. به هر حال دستور DENY بر تمامي دستورات مجوز ديگر اولويت دارد. در نتيجه كاربري كه مجوز وي توسط DENY لغو شده است، نمي‌تواند آن را از نقش ديگر به ارث ببرد. توجه: اعضاي نقش سروري ثابت sysadmin و مالكان اشياء را نمي‌توان توسط دستور DENY لغو مجوز كرد. 2-5- زنجيره هاي مالكيت SQL Server اين اطمينان را ايجاد مي‌كند كه فقط كساني كه داراي مجوز هستند به اشياء دسترسي داشته باشند. زماني كه چندين شيء پايگاه داده به يكديگر دسترسي پيدا مي‌كنند، اين توالي تحت عنوان زنجيره شناخته مي‌شود. زماني كه SQL Server لينك‌هاي اين زنجيره را مي‌پيمايد، مجوزها را به گونه‌اي متفاوت با زماني كه به هر آيتم به صورت مجزا دسترسي پيدا مي‌كند، ارزيابي مي‌نمايد. زماني كه يك شيء از طريق يك زنجيره مورد دسترسي قرار مي‌گيرد، SQL Server ابتدا مالك شيء را با مالك شيء فراخواننده (لينك قبلي زنجيره) مقايسه مي‌كند. درصورتي كه هر دو شيء مالك يكسان داشته باشند، مجوزهاي شيء دوم بررسي نمي‌گردند. اما در صورتي كه يك شيء به فراخواني شيء ديگري بپردازد كه مالكان يكساني نداشته باشند، زنجيره مالكيت شكسته مي‌شود و SQL Server بايد وضعيت امنيتي فراخواننده را بررسي نمايد. 2-6- كد procedural و زنجيره مالكيت تصور كنيد كه يك كاربر مجوزهاي اجرا را بر روي يك روال ذخيره شده كه داده ها را از يك جدول انتخاب مي‌كند، دريافت كرده باشد. درصورتي كه روال ذخيره شده و جدول داراي مالك يكسان باشند، كاربر نيازي به دريافت مجوز بر روي جدول نخواهد داشت و حتي مجوزهاي وي مي‌توانند ابطال گردند. اما درصورتي كه روال ذخيره شده و جدول مالكان متفاوتي داشته باشند، SQL Server بايد پيش از دسترسي به داده‌ها، مجوزهاي كاربر را بر روي جدول بررسي نمايد.
  11. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت‌هاي پيشين مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server و انواع سناريوهاي احراز هويت در SQL Server پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به توضيح مالكيت و جداسازي schema ها در SQL Server مي‌پردازد. 2- مالكيت و جداسازي User-Schema در SQL Server Schemaدر سيستم پايگاه داده‌ها، ساختاري است كه توسط زبان رسمي DBMSپشتيباني مي‌شود. در بانك اطلاعاتي رابطه‌اي، Schema مشخص كننده جداول، فيلدها، روابط، نماها(Views)، انديكس‌ها، فانكشن‌ها ، رويه‌ها و ديگر عناصر هستند. در حقيقت Schemaمانند ظرفي است كه براي نگهداري اشياي پايگاه داده از آن استفاده مي‎شود. يكي از مفاهيم هسته‌اي امنيت در SQL Server اين است كه مالكان اشياء، مجوزهاي غير قابل بازپس‌گيري براي مديريت اشياء داشته باشند. شما نمي‌توانيد حقوق دسترسي را از مالك يك شيء بگيريد و درصورتي‌كه كاربران مالك اشيايي در يك پايگاه داده باشند، نمي‌توانيد آنها را از پايگاه داده حذف نماييد. 2-1- جداسازي User-Schema جداسازي User-Schema انعطاف‌پذيري بيشتري در مديريت مجوزهاي اشياي پايگاه داده ايجاد مي‌كند. يك Schema عبارت است از يك كانتينر نام‌گذاري شده براي اشياي پايگاه داده كه به شما اجازه مي‌دهد اشيا را در namespace هاي مجزا گروه‌بندي كنيد. براي مثال، پايگاه داده نمونه AdventureWorks شامل schema هايي براي توليدات، فروش و منابع انساني است. دستور نام‌گذاري چهار بخشي براي اشياء، نام schema را مشخص مي‌كند. Server.Database.DatabaseSchema.DatabaseObject 2-2- مالكان و مجوزهاي schema هريك از كابران و نقش‌هاي پايگاه داده مي‌توانند مالك Schema ها باشند و در عين حال يك كاربر مي‌تواند در آن واحد مالك چندين schema باشد. شما مي‌توانيد قوانين امنيتي (security rules) مد نظر خود را بر روي يك schema اعمال نماييد كه اين قوانين توسط تمامي اشياي آن schema به ارث برده مي‌شوند. همچنين درصورتي‌كه شما مجوزهاي دسترسي را براي يك schema تنظيم كنيد، اين مجوزها در هنگام اضافه شدن يك شيء جديد به schema، به‌طور خودكار بر روي آن شيء نيز اعمال مي‌گردند. كاربران مي‌توانند يك schema ي پيش‌فرض تخصيص يافته داشته باشند و چندين كاربر پايگاه داده مي‌توانند يك schema را به اشتراك بگذارند. هنگامي‌كه توسعه‌دهندگان اشيايي را در يك schema ايجاد مي‌كنند، به‌طور پيش‌فرض مالك هر شيء همان مالك schema است و نه توسعه دهنده شيء. البته مالكيت يك شيء مي‌تواند توسط دستور ALTER AUTHORIZATION Transact-SQL از فردي به فرد ديگر انتقال يابد. همچنين يك schema مي‌تواند اشيايي را در بر بگيرد كه مالكان آنها كاربران مختلف هستند و مجوزهاي جزئي‌تري نسبت به مجوزهاي schema دارند. البته اين مورد چندان توصيه نمي‌شود، چرا كه انجام اين كار مديريت مجوزهاي اشياء و schema ها را پيچيده‌تر مي‌كند. اشياء مي‌توانند بين schema ها حركت كنند و مالكيت schema نيز مي‌تواند بين كاربران و نقش‌هاي پايگاه داده جابه‌جا شود. و در نهايت اينكه كاربران پايگاه داده مي‌توانند بدون تأثير بر schema ها حذف گردند. 2-3- schema هاي از پيش تعريف شده SQL Server به همراه ده schema ي از پيش تعريف شده به فروش مي‌رسد كه نام‌هاي يكساني با كاربران و نقش‌هاي پيش‌ساخته پايگاه داده دارند. شما مي‌توانيد schema هايي كه نام‌هاي يكساني با نقش‌هاي ثابت پايگاه داده دارند را درصورت عدم نياز به آنها حذف نماييد. اما نمي‌توانيد schema هاي زير را حذف كنيد: Dbo Guest Sys INFORMATION_SCHEMA در صورتي‌كه اين schema ها را از پايگاه داده مدل حذف كنيد، در پايگاه‌هاي داده جديد ظاهر نخواهند شد. نكته Schema هاي sys و INFORMATION_SCHEMA براي اشياي سيستمي رزرو شده‌اند. شما نمي‌توانيد اشياء را در اين schema ها ايجاد كرده و يا حذف نماييد. 2-4- schema ي dbo Schema ي dbo همان schema ي پيش‌فرض براي پايگاه داده‌اي است كه جديداً ايجاد شده است. schema ي dbo توسط حساب كاربري dbo مالكيت مي‌گردد. به طور پيش فرض كاربراني كه توسط دستور CREATE USER Transact-SQL ايجاد مي‌شوند، dbo را به‌عنوان schema ي پيش‌فرض خود دارند. البته بايد به خاطر داشت كه كاربراني كه به schema ي dbo تخصيص يافته‌اند، مجوزهاي حساب كاربري dbo را به ارث نمي‌برند. در حقيقت هيچ مجوزي توسط كاربران از schema يي كه بدان تخصيص يافته‌اند به ارث برده نمي‌شود، بلكه مجوزهاي schema صرفاً توسط اشياي پايگاه داده اي كه در schema قرار دارند به ارث برده مي‌شوند. نكته هنگامي كه اشياي پايگاه داده با استفاده از يك نام تك بخشي مورد ارجاع قرار مي‌گيزند، SQL Server ابتدا به schema ي پيش فرض كاربر نگاه مي‌كند. درصورتي‌كه اين شيء در آنجا پيدا نشود، آنگاه SQL Server به schema ي dbo نگاه مي‌كند. اما اگر اين شيء در schema ي dbo نيز پيدا نگردد، يك خطا بازگردانده مي‌شود.
  12. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. در قسمت قبلي مجموعه مقالات امنيت SQL Server، به نماي كلي امنيت SQL Server و انواع سناريوهاي احراز هويت در SQL Server پرداختيم. اين بخش از اين مجموعه مقالات به طور مختصر به توضيح نقش‌هاي سرور و پايگاه داده در SQL Server مي‌پردازد. 2- نقش‌هاي سرور و پايگاه داده در SQL Server تمامي نسخه‌هاي SQL Server از امنيت مبتني بر نقش استفاده مي‌كنند كه به شما اجازه مي‌دهد مجوزها را به جاي افراد خاص، به يك نقش، يا يك گروه از كاربران اعطا كنيد. نقش‌هاي ثابت سرور و نقش‌هاي ثابت پايگاه داده داراي مجموعه‌اي ثابت از مجوزهاي مخصوص به خود هستند. 2-1- نقش‌هاي ثابت سرور نقش‌هاي ثابت سرور داراي مجموعه‌اي ثابت از مجوزها بوده و قلمرو آنها كل سرور است. اين نقش‌ها بدين منظور در نظر گرفته شده‌اند كه در مديريت SQL Server مورد استفاده قرار گيرند و مجوزهاي تخصيص يافته به آنها نمي‌تواند تغيير كند. لاگين‌ها مي‌توانند بدون داشتن يك حساب كاربري در يك پايگاه داده، به نقش‌هاي ثابت سرور اختصاص داده شوند. نكته امنيتي نقش ثابت سرور sysadmin شامل تمامي نقش‌هاي ديگر نيز مي‌شود و داراي قلمرو نامحدود است. اين نقش را به هيچ فردي اختصاص ندهيد، مگر اينكه بسيار قابل اعتماد باشند. اعضاي نقش sysadmin داراي حقوق دسترسي غيرقابل بازگشت در تمامي پايگاه‌هاي داده و منابع سرور هستند. در هنگام تخصيص نقش‌هاي ثابت سرور به كاربران، بهترين انتخاب‌ها را انجام دهيد. براي مثال، نقش bulkadmin به كاربران اجازه مي‌دهد محتويات هر فايل محلي را به يك جدول اضافه كنند كه مي‌تواند جامعيت داده‌ها را در معرض خطر قرار دهد. 2-2- نقش‌هاي ثابت پايگاه داده نقش‌هاي ثابت پايگاه داده داراي مجموعه‌اي از مجوزهاي از پيش تعريف شده هستند كه براي اين طراحي شده‌اند كه شما قادر باشيد به سادگي گروه‌هاي مجوزها را مديريت نماييد. اعضاي نقش db_owner مي‌توانند تمامي پيكربندي‌ها و فعاليت‌هاي نگهداري را بر روي پايگاه داده انجام دهند. لاگين‌ها براي اينكه بتوانند با اشياي پايگاه داده كار كنند، بايد به حساب‌هاي كاربري پايگاه داده نگاشت شوند. سپس حساب‌هاي كاربري پايگاه داده مي‌توانند به نقش‌هاي پايگاه داده اضافه گردند و تمامي مجموعه مجوزهاي مرتبط با آن نقش‌ها را به ارث ببرند. تمامي مجوزها مي‌توانند اعطا گردند. شما همچنين بايد در هنگام طراحي امنيت برنامه خود، نقش عمومي، حساب كاربري dbo و حساب كاربري مهمان را در نظر بگيريد. 2-3- نقش عمومي نقش عمومي در هر پايگاه داده‌اي از جمله پايگاه‌هاي داده سيستمي وجود دارد. اين نقش نمي‌تواند حذف گردد و شما نمي‌توانيد كاربران مورد نظر خود را به نقش عمومي افزوده يا از آن حذف نماييد. در حقيقت مجوزهاي اعطا شده به نقش عمومي توسط تمامي كاربران و نقش‌هاي ديگر به ارث برده مي‌شوند، چرا كه تمامي كاربران و تمامي نقش‌ها به‌صورت پيش‌فرض به نقش عمومي تعلق دارند. بنابراين بايد صرفاً مجوزهايي را به نقش عمومي تخصيص دهيد كه مي‌خواهيد تمامي كاربران آن مجوزها را در اختيار داشته باشند. 2-4- حساب كاربري dbo dbo يا صاحب پايگاه داده، يك حساب كاربري است كه مجوزهاي ضمني براي انجام تمامي فعاليت‌ها را در پايگاه داده دارا است. اعضاي نقش سرور ثابت sysadmin به‌طور خودكار به dbo نگاشت مي‌شوند. نكته حساب كاربري dbo اغلب با نقش ثابت پايگاه داده db_owner اشتباه گرفته مي‌شود. اما بايد توجه داشت كه قلمرو db_owner فقط يك پايگاه داده است، درحالي‌كه قلمرو sysadmin كل سرور است. در نتيجه عضويت در نقش db_owner، حقوق دسترسي كاربر dbo را به همراه نخواهد داشت. 2-5- حساب كاربري مهمان پس از اينكه يك كاربر احراز هويت گرديد و مجوز لاگين كردن به SQL Server را دريافت كرد، بايد در هر پايگاه داده‌اي كه كاربر به آن دسترسي دارد يك حساب كاربري مجزا براي وي وجود داشته باشد. نياز به يك حساب كاربري جداگانه در هر پايگاه داده، از اتصال كاربر به يك نمونه SQL Server موجود بر روي يك سرور و دسترسي به تمامي پايگاه‌هاي داده موجود بر روي آن سرور جلوگيري مي‌كند. اما وجود يك حساب كاربري مهمان در پايگاه داده، اين مسأله را زير سؤال مي‌برد و مجوز لاگين بدون يك حساب كاربري پايگاه داده براي دسترسي به پايگاه داده را صادر مي‌نمايد. حساب كاربري مهمان يك حساب كاربري دروني در تمامي نسخه‌هاي SQL Server است. اين حساب در پايگاه‌هاي داده جديد به‌طور پيش‌فرض غيرفعال است. درصورتي‌كه حساب كاربري مهمان فعال باشد، شما مي‌توانيد اين حساب را با اجراي دستور Transact-SQL REVOKE CONNECT FROM GUEST و منع درخواست اتصال آن غيرفعال نماييد. نكته امنيتي از استفاده از حساب كاربري مهمان خودداري كنيد، چرا كه تمامي لاگين‌هاي بدون مجوز خاص پايگاه داده، مجوزهاي اعطا شده به اين حساب را دريافت مي‌كنند. درصورتي‌كه مجبور هستيد از حساب كاربري مهمان استفاده كنيد، حداقل حقوق دسترسي و حداقل مجوزها را به آن تخصيص دهيد.
  13. 1- مقدمه SQL Server ويژگي‌هاي زيادي دارد كه ايجاد برنامه‌هايي با پايگاه داده امن را پشتيباني مي‌كند. صرفنظر از نسخه SQL Server، ملاحظات امنيتي معمول مانندسرقت داده‌ها و جامعيت داده‌ها در اين نرم‌افزار در نظر گرفته مي‎شود. درصورتي‌كه داده‌ها محافظت نگردند، ممكن است به علت دستكاري و تغييرات غيرعمدي يا خرابكارانه پاك شوند يا تغيير يابند و ارزش خود را از دست بدهند. بعلاوه، اغلب بايد مسائلي مانند ذخيره‌سازي صحيح اطلاعات محرمانه نيز مورد توجه قرار گيرد. هر نسخه از SQL Server مانند هر نسخه از ويندوز، ويژگي‌هاي امنيتي متفاوتي نسبت به نسخه‌هاي پيشين خود دارد و نسخه‌هاي جديدتر، عملكرد بهتري نسبت به نسخه‌هاي پيشين دارند. اين مهم است كه درك كنيم كه ويژگي‌هاي امنيتي به تنهايي قادر به تضمين يك برنامه پايگاه داده امن نيستند. هر برنامه پايگاه داده از جهت ملزومات، محيط اجرا، مدل اجرا، موقعيت فيزيكي و تعداد كاربران منحصر به فرد است. ممكن است برخي برنامه‌هاي محلي نيازمند امنيت حداقلي باشند، درحالي‌كه ساير برنامه‌هاي محلي و يا برنامه‌هايي كه بر روي اينترنت به كار گرفته مي‌شوند ممكن است به معيارهاي امنيتي قوي‌تر و مانيتورينگ و ارزيابي دائم نياز داشته باشند. ملزومات امنيتي يك برنامه پايگاه داده SQL Server بايد در زمان طراحي در نظر گرفته شود نه پس از آن. ارزيابي تهديدات در ابتداي چرخه توسعه برنامه اين فرصت را در اختيار شما قرار مي‌دهد كه خسارت بالقوه را در هرجايي كه يك آسيب‌پذيري شناسايي مي‌شود، كاهش دهيد. حتي اگر طراحي اوليه يك برنامه بي‌عيب و نقص باشد، باز هم تهديدات جديد ممكن است در زمان بهره‌برداري از سيستم رونمايي كنند. با ايجاد خطوط دفاعي مختلف براي پايگاه داده، مي‌توانيد خسارت وارد شده توسط يك نشت امنيتي را به حداقل برسانيد. نخستين خط دفاعي، كاهش سطح حمله با اعطاي مجوزهاي حداقلي و رعايت اصل حداقل دسترسي است. اين مقاله به طور مختصر به توصيح ويژگي‌هاي امنيتي در SQL Server كه مناسب توسعه دهندگان نرم‌افزار است مي‌پردازد. 2- نماي كلي امنيت SQL Server يك استراتژي دفاع در عمق با لايه‌هاي امنيتي همپوشان، بهترين راه براي روبرو شدن با تهديدات امنيتي است. SQL Server يك معماري امنيتي را ارائه مي‌دهد كه براي اين طراحي شده است كه مديران پايگاه داده و توسعه دهندگان نرم‌افزار بتوانند برنامه‌هاي پايگاه داده امن ايجاد كرده و با تهديدات مقابله نمايند. هر نسخه از SQL Server با معرفي ويژگي‌هاي جديد و عملكرد بهتر، نسبت به نسخه‌هاي پيشين آن بهبود يافته است. البته امنيت در يك جعبه به فروش نمي‌رسد. هر برنامه از جهت ملزومات امنيتي آن منحصر به فرد است. توسعه دهندگان نرم‌افزار بايد بدانند كدام تركيب از ويژگي‌ها و عملكردها بهترين انتخاب براي آنهاست تا با تهديدات شناخته شده مقابله كرده و در برابر تهديدات احتمالي آتي نيز آماده باشند. SQL Server شامل مجموعه‌اي سلسله‌مراتبي از نهادهاست كه با سرور آغاز مي‌گردند. هر سرور شامل چندين پايگاه داده بوده و هر پايگاه داده شامل مجموعه‌اي از اشياي قابل امن‌سازي است. هر شيء قابل امن‌سازي SQL Server داراي مجوزهايي است كه مي‌توانند به يك فرد يا يك گروه تخصيص يابند. چارچوب كاري (framework) امنيتي SQL Server، دسترسي به نهادهاي قابل امن‌سازي را از طريق احراز هويت و تفويض اختيار مديريت مي‌نمايد. احراز هويت عبارت است از پروسه اتصال و ورود به SQL Server كه در آن، فرد با ثبت اطلاعات اعتباري (نام كاربري و كلمه عبور) خود و ارزيابي اين اطلاعات توسط سرور، مي‌تواند به سرور دسترسي پيدا كند. تفويض اختيار عبارت است از پروسه تصميم‌گيري در مورد اينكه فرد مي‌تواند به كدام منابع قابل امن‌سازي دسترسي داشته باشد و در مورد هريك از اين منابع مجوز انجام چه اعمالي را داراست. 2-1- احراز هويت در SQL Server SQL Server احراز هويت را در دو مود پشتيباني مي‌كند: مود احراز هويت ويندوز و مود تركيبي. احراز هويت ويندوز مود پيش‌فرض SQL Server است و اغلب تحت عنوان امنيت يكپارچه شناخته مي‌شود، چرا كه اين مدل امنيتي SQL Server به شكل تنگاتنگي با ويندوز يكپارچه شده است. حساب‌هاي كاربري خاص و گروهي ويندوز براي ورود و اتصال به SQL Server مورد اعتماد هستند. كاربران ويندوز كه كه پيش از اين احراز هويت شده باشند، نياز به ارائه مجدد اطلاعات خود ندارند. مود تركيبي احراز هويت را از هر دو طريق ويندوز و SQL Server پشتيباني مي‌كند. در اين مود، نام كاربري و كلمه عبور در داخل SQL Server نگهداري مي‌شود. نكته امنيتي توصيه مي‌شود تا جايي كه ممكن است از احراز هويت ويندوز استفاده كنيد. احراز هويت ويندوز از مجموعه‌اي از پيام‌هاي رمز شده براي احراز هويت كاربران در SQL Server استفاده مي‌كند. اما زماني كه لاگين‌هاي SQL Server مورد استفاده قرار مي‌گيرند، نام‌هاي لاگين و كلمات عبور SQL Server از طريق شبكه ارسال مي‌شوند كه از امنيت آنها مي‌كاهد. در احراز هويت ويندوز، كاربران قبلاً به ويندوز وارد شده‌اند و نياز نيست مجدداً و جداگانه به SQL Server وارد شوند. رشته ارتباطي زير بدون نياز به نام كاربري يا كلمه عبور، احراز هويت ويندوز را مورد استفاده قرار مي‌دهد: “Server=MSSQL1;Database=AdventureWorks;Integrated Security=true; نكته لاگين‌ها از كاربران پايگاه داده مجزا هستند. شما بايد به‌طور جداگانه لاگين‌ها يا گروه‌هاي ويندوز را بر كاربران يا نقش‌هاي پايگاه داده نگاشت (map) نماييد. سپس بايد مجوزهاي مورد نياز را به كاربران يا نقش‌ها اعطا كنيد تا به اشياي پايگاه داده دسترسي يابند. 2-1-1- سناريوهاي احراز هويت احراز هويت ويندوز در موارد زير اغلب بهترين انتخاب است: يك كنترل كننده دامنه وجود داشته باشد برنامه و پايگاه داده بر روي يك كامپيوتر قرار داشته باشند شما در حال استفاده از SQL Server Express يا LocalDB باشيد لاگين‌هاي SQL Server اغلب در موارد زير مورد استفاده قرار مي‌گيرند: زماني كه يك workgroup داشته باشيد كاربران از دامنه‌هاي متفاوت و غير قابل اعتماد متصل شوند برنامه‌هاي اينترنتي مانند ASP.NET نكته استفاده از احراز هويت ويندوز، لاگين‌هاي SQL Server را غيرفعال نمي‌سازد. با استفاده از ALTER LOGIN DISABLE Transact-SQL مي‌توانيد لاگين‌هاي با حق دسترسي بالاي SQL Server را غيرفعال نماييد. 2-1-2- انواع لاگين SQL Server سه نوع لاگين را پشتيباني مي‌كند: يك حساب كاربري محلي ويندوز يا حساب دامنه مورد اعتماد. SQL Server براي احراز هويت حساب كاربري ويندوز، به ويندوز تكيه مي‌كند. گروه ويندوز. اعطاي مجوز دسترسي به يك گروه ويندوز، به تمامي لاگين‌هاي كاربري ويندوز كه عضوي از آن گروه هستند دسترسي مي‌دهد. لاگين SQL Server. SQL Server نام كاربري و عبارت درهم‌سازي شده كلمه عبور را در پايگاه داده اصلي ذخيره مي‌كند و با استفاده از روش‌هاي احراز هويت داخلي، اطلاعات لاگين را اعتبارسنجي مي‌نمايد. 2-1-3- احراز هويت مود تركيبي درصورتي‌كه بايد از احراز مود تركيبي استفاده كنيد، بايد لاگين‌هاي SQL Server ايجاد كنيد كه در SQL Server ذخيره مي‌شوند. سپس بايد در زمان اجرا، نام كاربري و كلمه عبور SQL Server را وارد نماييد. نكته امنيتي SQL Server به همراه يك لاگين SQL Server به نام sa (system administrator) نصب مي‌گردد. به اين لاگين يك كلمه عبور بسيار قوي تخصيص دهيد و از اين لاگين در برنامه خود استفاده نكنيد. لاگين sa به نقش سروري ثابت sysadmin نگاشت مي‌گردد كه داراي اعتبارات مديريتي غيرقابل جبران در تمامي سرور است. درصورتي‌كه مهاجمي به عنوان مدير سيستم به SQL Server دسترسي پيدا كند، هيچ حدي براي خرابكاري وي وجود نخواهد داشت. تمامي اعضاي گروه BUILTIN\Administrators ويندوز به‌طور پيش‌فرض عضو نقش sysadmin نيز هستند، ولي مي‌توانند از اين نقش حذف گردند. درصورتي‌كه SQL Server بر روي ويندوز سرور 2003 يا نسخه‌هاي پس از آن اجرا گردد، از مكانيزم‌هاي سياست كلمه عبور ويندوز براي لاگين‌هاي SQL Server استفاده مي‌كند. سياست‌هاي پيچيدگي كلمه عبور براي اين طراحي شده‌اند كه با افزايش تعداد كلمات عبور ممكن، امكان حدس زدن آن را از طريق حملات ديكشنري به صفر نزديك كنند. SQL Server مي‌تواند سياست‌هاي پيچيدگي و انقضاي كلمه عبور مورد استفاده در ويندوز سرور 2003 را به كلمات عبور مورد استفاده در داخل SQL Server تعميم دهد. نكته امنيتي الصاق رشته‌هاي ارتباط از ورودي كاربر مي‌تواند شما را در برابر يك حمله تزريق رشته ارتباط آسيب‌پذير سازد. از SqlConnectionStringBuilder براي ايجاد رشته‌هاي معتبر ارتباط در زمان اجرا استفاده كنيد.
  14. Microsoft SQL Server محصولی از شرکت معروف مایکروسافت می باشد که برای مدیریت بانک های اطلاعاتی مورد استفاده قرار می گیرد. در این نرم افزار ابزارهای بسیار مختلفی به منظور ایجاد و مدیریت پایگاه داده ها و بانک های اطلاعاتی وجود دارد که شما می توانید با استفاده از آنها یک بانک عظیم اطلاعاتی ایجاد کنید و بر روی اطلاعات موجود در آن مدیریت نمایید. علاوه بر این یکی از ویژگی های مهم این برنامه امنیت بسیار بالای آن می باشد که سبب شده تا کاربران با خیال راحت از آن برای محافظت از اطلاعات خود استفاده نمایند. این نرم افزار به گونه ای طراحی شده که همه بتوانند از آن استفاده کنند به عنوان مثال برخی از کشورها برای مدیریت بانک های اطلاعاتی محرمانه خود از این نرم افزار بهره میگیرند و همچنین یک کاربر عادی به آسانی میتواند از این برنامه برای مدیریت اطلاعات خود در ویندوز و یا وب سایت شخصی خود استفاده کند. تا به حال مایکروسافت نسخه های مختلفی از این نرم افزار را منتشر نموده که نسخه 2012 جدید ترین نسخه آن می باشد و در مقایسه با نسخه های قدیمی، امکانات جدیدی به آن اضافه شده و ویژگی های قدیمی برنامه نیز ارتقا یافته است. برخی از ویژگی های این نرم افزار شامل امکان جدید Master Data Services برای مدیریت متمرکز SQL Server های مختلف، بهبود عملکرد هسته Database نرم افزار، امکان جدید Backup Compression به منظور کاهش حجم نسخه پشتیبان اطلاعات، پردازش تا 64 پروسه به صورت همزمان، امکان جدید Configuration Servers برای مدیریت چندین سرور، پشتیبانی از فایل های با فرمت XML، بهبود عملکرد قسمت های Analysis Services, Integration Services, Replication, Reporting Services, Service broker و ... می باشد. ورژن 2017 - نسخه 64 بیتی دانلود نسخه Enterprise با لینک مستقیم و حجم 1.33 گیگابایت دانلود نسخه Standard با لینک مستقیم و حجم 1.33 گیگابایت SQL Server Management Studio ورژن 2016 - نسخه 64 بیتی دانلود نسخه Enterprise SP2 دانلود نسخه Standard SP2 دانلود فایل جدا آپدیت به SP1 دانلود فایل جدا آپدیت به SP2 ورژن 2014 نسخه All Edition دانلود نسخه 32و64 بیتی تمام نسخه های SP3 در 1 فایل با لینک مستقیم ورژن 2012 دانلود نسخه 32/64 بیتی با لینک مستقیم ورژن 2008 دانلود نسخه 32/64 بیتی با لینک مستقیم
  15. NoSQL چیست؟ آیا تاکنون از خود پرسیده اید گوگل چگونه در کسری از ثانیه در میلیاردها صفحه اینترنت جستجو میکند؟ آیا از SQL استفاده میکند؟ مسلما خیر, از تکنولوژی جدیدی به نام NoSQL استفاده میکند! رایج ترین دسته دیتابیس ها امروزه بر مبنای SQL میباشند و اینگونه دیتابیس ها “ارتباطی” یا “relational” نامیده میشوند. اما با پیشرفت تکنولوژی طی سالیان اخیر نیاز به پردازش و ذخیره سازی بهینه تر , سرعت بالا و عدم امکان استفاده از جداول (Table) در بسیاری از پروژه های بزرگ احساس میشد. از طرفی ذخیره سازی حجم بالایی از داده های بدون ساختار (non-structured data) در دیتابیس های SQL باعث کاهش شدید سرعت و کارایی دیتابیس میگردد. از این رو تکنولوژی جدیدی به نام NoSQL با اهدافی متفاوت ارائه شد. هدف اصلی NoSQL ذخیره سازی و کار با داده های بدون ساختار و حجیم میباشد. متاسفانه این علم روز جهانی در داخل کشورمان تاکنون زیاد مورد بحث و استفاده قرار نگرفته است. در ادامه به بررسی عملکرد قابل توجه و انواع آن میپردازیم… ساختار و عملکرد SQL قبل از پرداختن به ساختار NoSQL باید کمی با SQL دقیق تر آشنا شویم. دیتابیس های SQL نحوه عملکرد سازمان یافته و سفت و سخت تری در ذخیره سازی و دریافت اطلاعات دارند. اگر تاکنون با SQL کار کرده باشید میدانید که اطلاعات درون جداول (Tables) – ستون ها (Columns) – سطرها (Rows) ذخیره میشوند. به زبان ساده در SQL: هر سطر (Row) نقش یک رشته ورودی یا خروجی را دارد. هر ستون (Column) نقش یک خصوصیت یا شاخص را دارد. هر جدول (Table) نقش یک خوشه اطلاعات با خصوصیات مشترک را دارد. همچنین در SQL میتوانیم هر جدول را به جدول دیگری ارتباط بدهیم و جداول مرتبط با هم بسازیم. تمامی این ارتباطات و ساختارهای داده ای مرتبط با هم در پشت صحنه توسط دیتابیس به واسطه ساختاری به نام Schema ذخیره میشوند. اما به علت ثابت بودن ماهیت دیتابیس های SQL , ساختار هر دیتابیس مانند پی ساختمان توسط Schema ثابت تعریف شده است. (Predefined Schema) این قائده مندی و ساختاردهی در بسیاری از موارد کاربردی و مفید میباشد. در کل SQL بسیار پایدار (Stable) و مناسب برای داده های خصوصیت دار و ساختاریافته میباشد. اما در مورد ذخیره سازی داده های بسیار بزرگ و بدون ساختار مشخص, ناگهان نقاط قوت آن به نقاط ضعف تبدیل میشوند و چهارچوب ها و مقررات سفت و سخت ذخیره سازی و کار با داده ها در SQL باعث محدود شدن قابلیت ذخیره سازی اطلاعات متفاوت در کنار هم و کاهش چشمگیر کارایی و سرعت میگردد. ساختار و عملکرد NoSQL خلاء ایجاد شده توسط نقاط ضعف SQL در کار با داده های حجیم باعث ایجاد و توسعه NoSQL شد. NoSQL قابلیت مدیریت کردن و کار با حجم بسیار عظیمی از داده ها را داراست. مشخصا در آن برای کار با داده ها از زبان SQL استفاده نمیشود. بلکه به صورت بسیار ساده و روان از XML یا JSON برای این منظور استفاده میگردد. از آنجایی که NoSQL باید بتواند انواع مختلف داده های بدون ساختار مشخص را ذخیره کند, در ساختار داخلی آن از “Schema پویا و قابل تغییر” یا “Dynamic Schema” استفاده شده است. این خصوصیت امکان تغییر در ساختار ذخیره سازی داده ها را فراهم کرده و انعطاف فراوانی به دیتابیس در کار با داده های گوناگون و حجیم میدهد. با این حال از نقاط ضعف NoSQL میتوان به عدم امکان کار با کوئری های پیچیده اشاره کرد. همچنین به نسبت دقت بالای SQL در NoSQL امکان بروز خطاهایی با احتمال بسیار پایین در موقع ثبت و تغییر داده ها وجود دارد. (ریسک پیش آمدن حالت های پیش بینی نشده توسط مدیر دیتابیس, هر چند اندک وجود دارد. مدیر دیتابیس باید با شناخت کامل خصوصیات دیتابیس خود, آن را جهت حفط یکپارچگی داده ها به صورت صحیح مدیریت کند.) دسته های مختلفی از دیتابیس های NoSQL تاکنون ساخته شده اند. در ادامه به بررسی هر کدام میپردازیم. انوع مختلف NoSQL دیتابیس های NoSQL کلید و مقدار (Key-value NoSQL): در اینگونه دیتابیس ها از یک کلید (Key) که نقش شناسه هر داده را بازی میکند به منظور دریافت و ذخیره سازی داده (Value) استفاده میشود. این دسته به علت سادگی کارکرد پر استفاده ترین نوع دیتابیس های NoSQL میباشد. دیتابیس های NoSQL اسناد (Document NoSQL): اینگونه دیتابیس ها به منظور ذخیره سازی و کار با اسنادی با فرمت های XML, JSON , … به کار میروند. از دیتابیس های اسنادی NoSQL به منظور ذخیره سازی داده های بدون ساختار مشخص با پراکندگی بالا استفاده میشود. دیتابیس های NoSQL چند ستونه (Wide-column NoSQL): دیتابیس های چند ستونه در نگاه اول همانند دیتابیس های SQL از جدول و ستون و سطر استفاده میکنند. اما عملکرد آن های ارتباطی به جداول SQL ندارد! فقط ظاهر جداول آن ها تا حدی شبیه ساختار جداول SQL میباشد. بر خلاف SQL هر ستون میتواند شامل داده هایی با فرمت و ساختار متفاوت باشد. به عبارتی دیگر نوع تعریف و فرمت یک ستون میتواند در هر سطر متفاوت باشد. این دیتابیس ها انعطاف بسیار بالایی در ثبت و کار با داده های بسیار عظیم و متفاوت دارند. دیتابیس های NoSQL گرافی (Graph NoSQL): دیتابیس های گرافی به منظور ذخیره سازی حجم زیادی از داده های ارتباطی (Relational data) طراحی شده اند. به زبان ساده میتوان اینگونه دیتابیس ها را مانند گرافی شامل “داده ها -> راس ها” و “ارتباط ها -> یال ها” در یک گراف هندسی در نظر گرفت. از این دسته دیتابیس ها در ذخیره سازی انواع معماری های داده های شبکه ای نیز استفاده میشود. دیتابیس های NoSQL متغیر یا چند مدله (MultiModel NoSQL): دیتابیس های چند مدله امکان ذخیره سازی و کار با داده ها را در چندین حالت متفاوت فراهم میکنند. اینگونه دیتابیس ها میتوانند تلفیقی از انوع دیگر دیتابیس های NoSQL باشند. (مانند Key-value و گرافی) NoSQL جایگزین کامل SQL نیست! باید دقت داشت که NoSQL و SQL هر کدام کاربردهای متفاوتی دارند. همانطور که گفته شد SQL دقت بالاتری در هنگام کار با داده های کوچک دارد و برای کار با داده های ساختاریافته طراحی شده است. در حالی که NoSQL برای کار با داده های کلان و بدون ساختار مشخص طراحی شده است. از جمله سیستم هایی که SQL در آن ها بهینه عمل میکند میتوان به موارد زیر اشاره کرد: سیستم های مدیریت سطح دسترسی (Access Control). (مثال: مدیریت کاربران سایت و سیستم ها) سیستم های تراکنش بانکی … از جمله سیستم هایی که NoSQL در آن ها بهینه عمل میکند میتوان به موارد زیر اشاره کرد: کلان داده (Big data) موتورهای جستجوگر سیستم های مانیتورینگ و پویش شبکه … چرا سازمان ها نیاز به مهاجرت به NoSQL دارند؟ در چند سال اخیر افزایش بسیار زیادی در نرخ تولید و جمع آوری داده ها رخ داده است. همچنین سازمان ها با داده های ورودی گوناگون و متنوعی رو به رو هستند. در نتیجه حجم و گوناگونی داده هایی که سازمان نیاز به مدیریت و کار با آن ها دارد بسیار افزایش داشته است. چنین امری سازمان ها را ملزم به بروزرسانی سیستم های سنتی مدیریت دیتابیس (DBMS) به سیستم های نوینی میکند, که امکان بررسی و آنالیز داده هایی عظیم که هر لحظه افزوده میشوند را داشته باشد. همچنین بسیاری از داده هایی که سازمان ها با آن سر و کار دارند داده های بدون ساختار مشخص هستند و امکان تعریف تعداد بسیار زیادی جدول و فیلد در دیتابیس های SQL غیر منطقی به نظر میرسد. در نتیجه استفاده از تکنولوژی های پیشرفته ای مانند NoSQL باعث از بین رفتن محدودیت های فنی ذخیره سازی داده ها و اطلاعات میشود. مهاجرت از SQL به NoSQL گرچه فرایندی سخت و هزینه بر میباشد, اما با تشخیص صحیح مدیر دیتابیس باعث بهینه تر شدن عملکرد چشمگیر سیستم های اطلاعاتی میشود. قابلیت توسعه و پایداری بالای NoSQL در کار کردن با حجم داده های بالا, با SQL قابل قیاس نیست. معرفی برخی از دیتابیس های NoSQL Aerospike: اگر به دنبال دیتابیس Key-value بسیار قدرتمند برای کلاسترینگ میگردید aerospike گزینه مناسبی میباشد. این دیتابیس از لحاظ حجم پردازش داده و سرعت بالاترین رتبه را در Benchmark بدست آورده است. ذخیره سازی اطلاعات در این دیتابیس به صورت ادغامی از Ram و SSD صورت میگیرد. Redis: یک دیتابیس Key-value که برای حجم کار کوچکتر به نسبت aerospike مناسب میباشد. تمامی اطلاعات این دیتابیس در Ram ذخیره میشوند. این دیتابیس قابلیت کلاستر شدن ندارد! MongoDB: مونگو معروف ترین دیتابیس NoSQL است و برای ذخیره سازی اسناد (Documents) استفاده میشود. اگر نیار به ذخیره سازی حجم بالایی از داده های مختلف و پراکنده را دارید مونگو گزینه مناسبی برای شماست. کار کردن با مونگو به نسبت ساده است و اگر قصد شروع کار و آشنایی با NoSQL ها را دارید شخصا آن را پیشنهاد میکنم. Cassandra: این دیتابیس از قوی ترین دیتابیس های NoSQL میباشد و توسط Apache ارائه شده است. دیتابیس Cassandra در دسته Wide-column قرار دارد. قابلیت های بسیار خاص و بالا, Cassandra را از بسیاری از NoSQLهای دیگر برتر میکند. گرچه سرعت پردازش Aerospike از Cassandra بیشتر است اما قابلیت های فراوان و انعطاف بالای Cassandra به عقیده بسیاری آن را قدرتمندترین NoSQL کرده است. Neo4j: دیتابیسی بر پایه گراف (Graph) که برای ذخیره سازی ساختمان داده های مختلف شبکه ای و داده های ارتباطی بسیار مناسب میباشد.
  16. Mr.Source

    New Google SQL Dorks-2019 view_items.php?id= home.php?cat= item_book.php?CAT= www/index.php?page= schule/termine.php?view= goods_detail.php?data= storemanager/contents/item.php?page_code= view_items.php?id= customer/board.htm?mode= help/com_view.html?code= n_replyboard.php?typeboard= eng_board/view.php?T****= prev_results.php?prodID= bbs/view.php?no= gnu/?doc= zb/view.php?uid= global/product/product.php?gubun= m_view.php?ps_db= productlist.php?tid= product-list.php?id= onlinesales/product.php?product_id= garden_equipment/Fruit-Cage/product.php?pr= product.php?shopprodid= product_info.php?products_id= productlist.php?tid= showsub.php?id= productlist.php?fid= products.php?cat= products.php?cat= product-list.php?id= product.php?sku= store/product.php?productid= products.php?cat= productList.php?cat= product_detail.php?product_id= product.php?pid= view_items.php?id= more_details.php?id= county-facts/diary/vcsgen.php?id= idlechat/message.php?id= podcast/item.php?pid= products.php?act= details.php?prodId= socsci/events/full_details.php?id= ourblog.php?categoryid= mall/more.php?ProdID= archive/get.php?message_id= review/review_form.php?item_id= english/publicproducts.php?groupid= news_and_notices.php?news_id= rounds-detail.php?id= gig.php?id= board/view.php?no= index.php?modus= news_item.php?id= rss.php?cat= products/product.php?id= details.php?ProdID= els_/product/product.php?id= store/description.php?iddesc= socsci/news_items/full_story.php?id= naboard/memo.php?bd= bookmark/mybook/bookmark.php?bookPageNo= board/board.html?table= kboard/kboard.php?board= order.asp?lotid= goboard/front/board_view.php?code= bbs/bbsView.php?id= boardView.php?bbs= eng/rgboard/view.php?&bbs_id= product/product.php?cate= content.php?p= page.php?module= ?pid= bookpage.php?id= cbmer/congres/page.php?LAN= content.php?id= news.php?ID= photogallery.php?id= index.php?id= product/product.php?product_no= nyheder.htm?show= book.php?ID= print.php?id= detail.php?id= book.php?id= content.php?PID= more_detail.php?id= content.php?id= view_items.php?id= view_author.php?id= main.php?id= english/fonction/print.php?id= magazines/adult_magazine_single_page.php?magid= product_details.php?prodid= magazines/adult_magazine_full_year.php?magid= products/card.php?prodID= catalog/product.php?cat_id= e_board/modifyform.html?code= community/calendar-event-fr.php?id= products.php?p= news.php?id= StoreRedirect.php?ID= subcategories.php?id= tek9.php? template.php?Action=Item&pid= topic.php?ID= tuangou.php?bookid= type.php?iType= updatebasket.php?bookid= updates.php?ID= view.php?cid= view_cart.php?title= view_detail.php?ID= viewcart.php?CartId= viewCart.php?userID= viewCat_h.php?idCategory=