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

[حمیدرضاصادقیان]

سلام.
همه میدونیم که دوراه برای ایجاد امنیت در دیتابیس وجود داره.یکی WINDOWS AUTHENTICATION و دومیش SQl Authentication هست.هرکدوم یک سری مزیتها دارن.
میخواستم ببینم دوستان کدوم یکی رو بیشتر می پسندن. و از لحاظ امنیتی کدوم بهتره.؟
باتشکر.

[shahab2025]

سلام
من از لحاط راحتی از حالت windows بیشتر بهره میبرم ولی برای کاربر ترجیح میدهم کانکشن با حالت sql برقرار بشه اونم نه با sa (با کاربر دیگری)

[AminSobati]

سلام دوست عزیزم،
اگر SQL Server 2008 Books Online دارین این لینک مطالب مفیدی بهتون میده:

ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10de_4deptrbl/html/ff7a6a48-3d38-4209-aa0f-7d6c0a8c64ef.htm

[sunn789]

مطمئناً استفاده از امنیت خود ویندوز بیشتر خواهد بود

[حمیدرضاصادقیان]

سلام.خوب الان اینجا چند سوال مطرحه.
وقتی من برنامه رو در شرکتهای مختلف نصب میکنم اگر از طریق ویندوز بخوام وصل بشم باید به تک تکشون مراجعه کنم و این یوزرها رو در خود sql تعریف کنم و بهشون دسترسی بدم.که خود این یک مشکل هست.
دوم اینکه من یک سری هم کاربر تعریف میکنم از داخل برنامه ام.درحال حاضر تمامی اجزا در برنامه ام رو داخل یک جدول گذاشتم و با مقدار دهی به اون فیلدها دسترسی رو در برنامه اعمال میکنم.آیا این روش درسته. یا اینکه بیام در خود sql server از role ها و schema ها و ... استفاده کنم.
سوال سوم اینکه من فرض کنید از همین اجزا استفاده کردم.چطور باید در برنامه مشخص کنم که وقتی کاربری رو تعریف کرد باید این دسترسی ها رو بهش بدم.؟ یعنی باید به ازا هر کاربری که در برنامه تعریف میشه من یک یوزر در sql ایجاد کنم و تمامی این دسترسی ها رو بهش بدم؟
باتشکر.

[AminSobati]

اینکه شما همیشه با یک کاربر از Application به دیتابیس وصل میشین و سطوح دسترسی رو خودتون در جداول یا XML تعریف میکنید، روش اشتباهی نیست و اصطلاحا Hand-Roled Security نامیده میشه. درصد قابل توجهی از نرم افزارها چنین مکانیزمی دارند. استفاده از روشهای خود SQL Server در بعضی شرایط الزامی میشه. فرض کنید یک دیتابیس مرکزی به چند شرکت سرویس میده که خودشون Application مورد نیاز رو Develop میکنند. در این حالت، شاید به ازای هر شرکت و نیازهای اون، دسترسی رو جداول خاصی اعطا بشه.
از طرفی بعضا نحوه دسترسی که ما در Application نیاز داریم، اصلا قابل انطباق با ساختار Security در SQL Server نیست لذا از روش Hand-Roled استفاده میکنیم

[حمیدرضاصادقیان]

ممنون امین جان بابت توضیحات کاملت.آخه یک چیزی که چند وقته ذهن منو مشغول کرده اینه که برنامه هایی مانند همکاران سیستم اومدن در sql 2000 از تمامی پارامترهایی که برای امنیت در برنامه هست استفاده کردند.مثلا جداول هر سیستم رو براش یک یوزر تعریف کردن و owner همشو جداکردن. بعد به هرکدوم از یوزرها یک سری دسترسی دادند.بعد داخل برنامه میان کاربر تعریف میکنند و مشخص میکنند که هرکاربر چه دسترسی هایی داره.
حالا میخوام بدونم چطور اون پارامترهایی که در sql تعریف شده به یوزرهایی که در برنامه تعریف میشه ارتباط میدن.
ممنون.

[AminSobati]

در SQL Server 2000 همونطور که میدونین آبجکتی به نام Schema وجود نداره و این کار رو میشه با ساخت User Name شبیه سازی کرد. به این شکل جداول و SPها و ... میتونن دسته بندی بشن. ممکنه در دیتابیسی که مثال زدین در همین حد از ساختار Security و امکانات SQL Server استفاده شده باشه.
حمید جان من حدودا 150 ساعت SQL Server برای پرسنل همکاران سیستم تدریس کردم و تا جاییکه از مباحثات این دوستان سر کلاس متوجه شدم، سطوح دسترسی Hand-Roled هستش

[حمیدرضاصادقیان]

ممنون.پس چه لزومی داشت بیان اینهمه تعریفات رو داخل خود sql server پیاده سازی کنند؟
البته من یک سرچ کردم مطلب زیر رو پیدا کردم در sql server 2005 .ممنون میشم در این مورد هم نظرتو بدی.

http://technet.microsoft.com/fa-ir/l...95(en-us).aspx
من اینجا گیج شدم که وقتی میشه از hand rolled استفاده کرد چه لزومی داره ما بیایم schema,role,application role,... تعریف کنیم.

[AminSobati]

SQL Server بعنوان یک بانک اطلاعاتی باید از هر لحاظ به Security مجهز باشه و نمیشه گفت با Hand-Roled همه چیز قابل کنترله. یک مثال بزنم:
در یک پروژه که تولید نرم افزار Total System بود، تعداد برنامه نویسانی زیادی درگیر کار بودند. دیتابیس از ماژولهای متنوعی تشکیل میشه: مالی، اداری، انبار، حقوق-دستمزد و ...
نیاز بود تا هر برنامه نویس به تناسب ماژولی که باهاش کار میکنه دسترسی خاص داشته باشه. مثلا برنامه نویسی که با بخش Stock کار میکنه، فقط روی Schemaی مربوط به stk و برنامه نویس بخش Financial فقط به Schemaیی به نام fin دسترسی داشته باشند. اینجا شما قادر نیستید دسترسی ALTER روی آبجکتها رو به صورت Hand-Roled ارائه کنین.

[حمیدرضاصادقیان]

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

[AminSobati]

اون لینک معروفیه، بهترین مقاله برای امنیت Cell Level یا Row Level هست. اگر شما بخوای دقیقا نیازهای نرم افزارت رو Map کنی به سطوح دسترسی SQL Server، میبایست برای هر کاربر یک Login بسازی و دسترسی بدی. ولی این رو در نظر بگیر که اگر کاربرت کمی سواد داشته باشه، با نصب Management Studio میتونه مستقیم به دیتابیس وصل بشه و چون بهش دسترسی دادی، خارج از چارچوب نرم افزارت، روی جداولی که اختیار داره تغییر اعمال کنه. اینجاست که Application Role وارد صحنه میشه!

[حمیدرضاصادقیان]

ممنون امین جان.توضیحات خیلی کاملی دادی. منظورت از application role چیه.؟ همون سطوح دسترسی که روی آبجکتها در sql اعمال میشه. یا همون application role خود sql منظورته.؟ با اون فقط به برنامه های خاص دسترسی میده؟ چون یک بار تست کردم ولی نتیجه نگرفتم.
ممنون

[AminSobati]

منظور همون Roleهایی که داخل دیتابیس هست و عضو نمیگیره بلکه Password داره. هر کس Password رو داشته باشه میتونه Role رو Active کنه و استفاده کنه. برای اینکه کاربر دسترسی زیادی نداشته باشه، فقط براش یک Login تعریف میکنند. در این حالت حتی با Management Studio هم نمیتونه کار خاصی انجام بده. اما در Application براش اون Role رو Active میکنن تا فقط به واسطه نرم افزار بتونه کار کنه

[حمیدرضاصادقیان]

امین جان ممنون. خیل توضیحات کاملی بود.الان تازه متوجه شدم.

[Pr0grammer]

http://www.barnamenevis.org/sh...d.php?t=189664