امنيت SQL Server – قسمت دهم – تخصيص مجوزهای سطح ركورد و ايجاد نقش‌های برنامه كاربردی

امنيت SQL Server – قسمت دهم – تخصيص مجوزهای سطح ركورد و ايجاد نقش‌های برنامه كاربردی

تاریخ ایجاد

شماره :IRCAR201409231
تاريخ: 18/6/93

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 با يك كاربر بدون لاگين امن‌تر است، چرا كه مبتني بر مجوز است نه مبتني بر كلمه عبور.
  • روال‌هاي ذخيره شده را با گواهينامه‌ها امضا كنيد و صرفاً مجوز اجراي روال‌ها را صادر كنيد.
برچسب‌ها