سلام.
همه میدونیم که دوراه برای ایجاد امنیت در دیتابیس وجود داره.یکی WINDOWS AUTHENTICATION و دومیش SQl Authentication هست.هرکدوم یک سری مزیتها دارن.
میخواستم ببینم دوستان کدوم یکی رو بیشتر می پسندن. و از لحاظ امنیتی کدوم بهتره.؟
باتشکر.
سلام.
همه میدونیم که دوراه برای ایجاد امنیت در دیتابیس وجود داره.یکی WINDOWS AUTHENTICATION و دومیش SQl Authentication هست.هرکدوم یک سری مزیتها دارن.
میخواستم ببینم دوستان کدوم یکی رو بیشتر می پسندن. و از لحاظ امنیتی کدوم بهتره.؟
باتشکر.
Telegram : @SQL_Server
سلام
من از لحاط راحتی از حالت windows بیشتر بهره میبرم ولی برای کاربر ترجیح میدهم کانکشن با حالت sql برقرار بشه اونم نه با sa (با کاربر دیگری)
سلام دوست عزیزم،
اگر SQL Server 2008 Books Online دارین این لینک مطالب مفیدی بهتون میده:
ms-help://MS.SQLCC.v10/MS.SQLSVR.v10.en/s10de_4deptrbl/html/ff7a6a48-3d38-4209-aa0f-7d6c0a8c64ef.htm
مطمئناً استفاده از امنیت خود ویندوز بیشتر خواهد بود
سلام.خوب الان اینجا چند سوال مطرحه.
وقتی من برنامه رو در شرکتهای مختلف نصب میکنم اگر از طریق ویندوز بخوام وصل بشم باید به تک تکشون مراجعه کنم و این یوزرها رو در خود sql تعریف کنم و بهشون دسترسی بدم.که خود این یک مشکل هست.
دوم اینکه من یک سری هم کاربر تعریف میکنم از داخل برنامه ام.درحال حاضر تمامی اجزا در برنامه ام رو داخل یک جدول گذاشتم و با مقدار دهی به اون فیلدها دسترسی رو در برنامه اعمال میکنم.آیا این روش درسته. یا اینکه بیام در خود sql server از role ها و schema ها و ... استفاده کنم.
سوال سوم اینکه من فرض کنید از همین اجزا استفاده کردم.چطور باید در برنامه مشخص کنم که وقتی کاربری رو تعریف کرد باید این دسترسی ها رو بهش بدم.؟ یعنی باید به ازا هر کاربری که در برنامه تعریف میشه من یک یوزر در sql ایجاد کنم و تمامی این دسترسی ها رو بهش بدم؟
باتشکر.
Telegram : @SQL_Server
اینکه شما همیشه با یک کاربر از Application به دیتابیس وصل میشین و سطوح دسترسی رو خودتون در جداول یا XML تعریف میکنید، روش اشتباهی نیست و اصطلاحا Hand-Roled Security نامیده میشه. درصد قابل توجهی از نرم افزارها چنین مکانیزمی دارند. استفاده از روشهای خود SQL Server در بعضی شرایط الزامی میشه. فرض کنید یک دیتابیس مرکزی به چند شرکت سرویس میده که خودشون Application مورد نیاز رو Develop میکنند. در این حالت، شاید به ازای هر شرکت و نیازهای اون، دسترسی رو جداول خاصی اعطا بشه.
از طرفی بعضا نحوه دسترسی که ما در Application نیاز داریم، اصلا قابل انطباق با ساختار Security در SQL Server نیست لذا از روش Hand-Roled استفاده میکنیم
ممنون امین جان بابت توضیحات کاملت.آخه یک چیزی که چند وقته ذهن منو مشغول کرده اینه که برنامه هایی مانند همکاران سیستم اومدن در sql 2000 از تمامی پارامترهایی که برای امنیت در برنامه هست استفاده کردند.مثلا جداول هر سیستم رو براش یک یوزر تعریف کردن و owner همشو جداکردن. بعد به هرکدوم از یوزرها یک سری دسترسی دادند.بعد داخل برنامه میان کاربر تعریف میکنند و مشخص میکنند که هرکاربر چه دسترسی هایی داره.
حالا میخوام بدونم چطور اون پارامترهایی که در sql تعریف شده به یوزرهایی که در برنامه تعریف میشه ارتباط میدن.
ممنون.
Telegram : @SQL_Server
در 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,... تعریف کنیم.
Telegram : @SQL_Server
SQL Server بعنوان یک بانک اطلاعاتی باید از هر لحاظ به Security مجهز باشه و نمیشه گفت با Hand-Roled همه چیز قابل کنترله. یک مثال بزنم:
در یک پروژه که تولید نرم افزار Total System بود، تعداد برنامه نویسانی زیادی درگیر کار بودند. دیتابیس از ماژولهای متنوعی تشکیل میشه: مالی، اداری، انبار، حقوق-دستمزد و ...
نیاز بود تا هر برنامه نویس به تناسب ماژولی که باهاش کار میکنه دسترسی خاص داشته باشه. مثلا برنامه نویسی که با بخش Stock کار میکنه، فقط روی Schemaی مربوط به stk و برنامه نویس بخش Financial فقط به Schemaیی به نام fin دسترسی داشته باشند. اینجا شما قادر نیستید دسترسی ALTER روی آبجکتها رو به صورت Hand-Roled ارائه کنین.
ممنون امین جان.پس الزاما اینطوری نیست هر ابجکتی که ما تعریف میکنیم باید از طریق خود نرم افزار هم به اون ربط پیدا کنه. پس عملا دو سطح دسترسی میشه(اینطوری که من فهمیدم) . یکی در سطح برنامه که با جداول اعمال میشه یکی در سطح دیتابیس که با ابجکتهایی که ایجاد میکنیم انجام میشه. حالا میشه این دوتا رو هم بهم متصل کرد یا خیر؟
اون لینک هم مشاهده کردی؟ دسترسی ردیف به ردیف رو مورد بررسی قرار داده .تکنیک جالبی توش به کار برده.
باتشکر.
Telegram : @SQL_Server
اون لینک معروفیه، بهترین مقاله برای امنیت Cell Level یا Row Level هست. اگر شما بخوای دقیقا نیازهای نرم افزارت رو Map کنی به سطوح دسترسی SQL Server، میبایست برای هر کاربر یک Login بسازی و دسترسی بدی. ولی این رو در نظر بگیر که اگر کاربرت کمی سواد داشته باشه، با نصب Management Studio میتونه مستقیم به دیتابیس وصل بشه و چون بهش دسترسی دادی، خارج از چارچوب نرم افزارت، روی جداولی که اختیار داره تغییر اعمال کنه. اینجاست که Application Role وارد صحنه میشه!
ممنون امین جان.توضیحات خیلی کاملی دادی. منظورت از application role چیه.؟ همون سطوح دسترسی که روی آبجکتها در sql اعمال میشه. یا همون application role خود sql منظورته.؟ با اون فقط به برنامه های خاص دسترسی میده؟ چون یک بار تست کردم ولی نتیجه نگرفتم.
ممنون
Telegram : @SQL_Server
منظور همون Roleهایی که داخل دیتابیس هست و عضو نمیگیره بلکه Password داره. هر کس Password رو داشته باشه میتونه Role رو Active کنه و استفاده کنه. برای اینکه کاربر دسترسی زیادی نداشته باشه، فقط براش یک Login تعریف میکنند. در این حالت حتی با Management Studio هم نمیتونه کار خاصی انجام بده. اما در Application براش اون Role رو Active میکنن تا فقط به واسطه نرم افزار بتونه کار کنه
امین جان ممنون. خیل توضیحات کاملی بود.الان تازه متوجه شدم.
Telegram : @SQL_Server