عدم دسترسی کاربران معمولی به دیتابیس طراحی شده

[hamide_kh]

سلام
با توجه به بحثی که در یکی از تاپیکهای همین انجمن وجود داشت و لزوم ایجاد یک تاپیک جدید در مورد نگهداری و دور نگاه داشتن جداول و ویو ها و پروسیجر ها و .... از دید کاربران معمولی من این تاپیک را را راه اندازی کردم تا دوستان بتونند امثال بنده را راهنمایی کنند
برای این که سر رشته بحث به دست دوستان بیاد من اون را در اینجا میذارم


اگر فردی به عنوان مثال دشمن بیاد و جدولها را پاک کنه به نظر شما از این کار چطور باید جلوگیری کرد؟



سلام.
بسیار خوب. سوال کاملا منطقی بنظر میرسه، اما لطفا قبل از اینکه من به این سوال پاسخ بدم، ابتدا بفرمایید که


سیستم مورد نظر چگونه Deploy شده؟
Web App هست یا Desktop App؟
اگر Desktop App هستش چگونه به دست مشتری رسیده؟
اگر Web App هستش، میزبان این بانک کی هست؟
چه کسانی اجازه استفاده از این نرم افزار رو دارن و تحت چه شرایطی؟
و بسیاری سوالات دیگه.
ببینید. وقتی شما میگید "دشمن"، باید این واژه رو معنی کنید. تعریف شما از واژه دشمن چیه؟ من سوال شما رو که خوندم، پیش خودم گفتم "قطعی برق" هم یک دشمن محسوب میشه. اما ممکنه شما تعریف دیگه ای از دشمن داشته باشید. این دشمن چطور به این بانک دسترسی داره؟ در واقع داده ها، از طریق چه Front End ای در معرض دست کاربران قرار میگیرن؟

لطفا سوال رو اینقدر "خاص" مطرح کنید، تا بتونم در چند پاراگراف بهش پاسخ بدم. در غیر اینصورت، من پاسخی برای سوال شما ندارم. به بیان دیگه، صحبت کردم در مورد امنیت سیستمی که بهش اشراف ندارم، مطلقا صحیح نیست.

پاورقی: پاسخ ساده انگارانه به سوال شما اینه که خوب، من از داده ها بصورت زمانبندی شده، Backup میگیرم، بنابراین هر وقت نیاز باشه میتونم داده ها رو به آخرین وضعیت پایدار برسونم. این پاسخ درسته، اما کاملا به Context ای بر میگرده که داریم در موردش صحبت می کنیم. امنیت، یه تیغ دو لبه هستش، که اگر اندکی روی این تیغ بلغزید، براحتی میتونید خودتون رو قربانی شده تصور کنید. آدمهای بدخواه (واژه بهتری هستش نسبت به دشمن)، بدنبال کوچکترین حفره امنیتی توی سیستم شما هستن. شما همونطور که نگران از دست رفتن داده هاتون در سطح بانک هستید، باید نگران "آسیب پذیری" در جزء جزء نقاط سیستم خودتون باشید. عموما افراد فکر میکنن که اگر بانکشون رو خیلی خیلی خوب محافظت کنن، دیگه افراد بدخواه نمیتونن به اونها صدمه بزنن. اما امنیت یک زنجیره هستش، که در این زنجیره، افراد بدخواه بدنبال گسستن یکی از حلقه های زنجیر هستن. وقتی حلقه ای گسسته شد، دیگه اهمیت نداره حلقه های دیگه چقدر قوی بوده باشند، چون دیگه زنجیری وجود نداره. اینهمه روضه خوندم که بگم برای ارزیابی یک سیستم از نظر امنیتی، ابتدا باید "تهدیدهای" میسر روی سیستم رو "مدل سازی" کنید. به چنین مدل سازی ای میگن Threat Modeling.

Threat Modeling روشهای متفاوتی داره و از دیدگاه مختلف، معانی متفاوتی میده:


از دید مهاجم، یا فرد بدخواه
از دید نرم افزار
از دید دارایی های موجود
و ...
مایکروسافت در SDL، روشهایی رو عنوان کرد که در حال حاضر برنامه های مایکروسافت بر اساس اون توسعه پیدا میکنن. توضیح این مطالب، حداقل چند جلد کتاب رو میتونه بخودش اختصاص بده که متاسفانه از حوصله بنده خارجه.


سلام خدمت شما دوست عزیز آقای موسوی

اول از تاخیری که داشتم عذخواهی کنم؟

ببنید بنده روی سیستمهای تجاری زیادی کار نکرده ام.
به عنوان شما برنامه ای را در نظر بگیرید که win application هست و بنده به ضورت حضوری خودم اون را راه اندازی می کنم و دیتا بیس روی سیستمی قرار داره که فردی اولا فضول(البته ببخشید) و ثانیا سنگ انداز و مشکل درست کن باهاش کار میکنه؟
حالا من چطور می تونم دسترسی هم چین فردی را به دیتابیس قطع و کوتاه کنم؟

اما در مورد مشکل برق که شما فرمودید فکر کنم میشه با بک آپ گرفتنهای به موقع حلش کرد ؟
و اما منتظر پاسخ دوستان علی الخصوص آقای موسوی هستیم

این هم لینک تاپیک قبلی
http://barnamenevis.org/forum/showthread.php?t=205510&page=2

[mehdi.mousavi]

سلام
با توجه به بحثی که در یکی از تاپیکهای همین انجمن وجود داشت و لزوم ایجاد یک تاپیک جدید در مورد نگهداری و دور نگاه داشتن جداول و ویو ها و پروسیجر ها و .... از دید کاربران معمولی من این تاپیک را را راه اندازی کردم تا دوستان بتونند امثال بنده را راهنمایی کنند برای این که سر رشته بحث به دست دوستان بیاد من اون را در اینجا میذارم و اما منتظر پاسخ دوستان علی الخصوص آقای موسوی هستیم این هم لینک تاپیک قبلی
http://barnamenevis.org/forum/showthread.php?t=205510&page=2

سلام.
از اینکه مطالب رو به این تاپیک انتقال دادید، سپاسگذارم. اینطوری منم یادم اومد که بحث در چه موردی بود و ... بسیار خوب. بریم سر اصل مطلب.

من متخصص RDBMS ها نیستم، بنابراین ممکنه در مطالبی که میگم چیزی جا بیفته، یا به مطلبی به اندازه کافی بها ندم. با در نظر گرفتن این مساله، حالا سعی می کنم به سوال شما پاسخ بدم.

برای محافظت از بانک در برابر حملات بدخواهانه، روشهای متفاوتی وجود داره اما در نظر گرفتن مطالبی که الان عنوان می کنم، باید حتمی باشه:

1. از قانون "حداقل امتیازات" پیروی کنید. یعنی به بانک و Object هایی که در بانک تعریف می کنید (از قبیل Table، View، Stored Procedure و ...) حداقل امتیازات رو برای "اجرای صحیح" دستورات اعطاء کنید. بعنوان مثال، اگر قراره فردی از دستور CREATE TABLE استفاده کنه، باید دسترسی به CREATE TABLE رو داشته باشه و دیگه نیازی نیست ownership شی XML schema collection رو داشته باشه!

2. از Password های پیش فرض دوری کنید. لیست این account ها بهمراه رمزهای پیش فرضشون روی اینترنت وجود داره و مهاجم میتونه براحتی با دیدن اونها، کنترل بانک شما رو در اختیار بگیره. در نتیجه شما باید در بازه های زمانی مشخصی اقدام به تغییر این رموز کنید تا بدین وسیله جلوی dictionary attack ها رو هم بگیرید. یکی از روشهای موجود، brute force attack هستش، که نرم افزارهای زیادی هم روی وب وجود داره که امکان این حمله رو برای مهاجم فراهم میکنه.

3. Patch هایی که توسط تولید کنندگان بانکها عرضه میشه، بلافاصله نصب کنید. در این مورد اینقدر سخن پراکنی شده که فکر نمیکنم لازم به توضیحی در این باب باشه.

4. ناحیه ای که ممکنه مورد حجوم قرار بگیره رو به حداقل خودش برسونید. توی Security مثالی وجود داره که میگه "حفاظت از خونه ای که تعداد پنجره های زیادی داره، خیلی دشوارتر از خونه ای هستش که فقط یکی دو پنجره داره"! در واقع میخوام بگم شما باید نقاط دسترسی به بانک رو تا حد ممکن، محدود کنید. اینطوری علاوه بر اینکه کار مهاجم دشوارتر میشه، کار شما هم هنگام وقوع یک حمله راحتتر میشه، چون دیگه می دونید که (احتمال زیاد، و نه 100%) از فلان دو نقطه نفوذ صورت گرفته.

5. دارایی های موجود (تو اینجا، منظورم اطلاعات موجود در بانک هستش) رو باید "ارزش گذاری" کنید و تا ببینید کدوم داده رو باید در بانک Encrypt کنید. Encryption هم باید بر اساس استانداردهای موجود صورت بگیره. یک مهاجم، همواره دوست داره که شما Custom Algorithm خودتون رو برای اینکار بنویسید، چون اون میدونه که اگر شما اینکارو کنید و از الگوریتمهای استاندارد استفاده نکنید، میتونه خیلی راحتت تر به سیستم حمله کنه و احتمال نفوذ پذیری بسیار بالاتره. بر خلاف باور (تقریبا) عمومی، استفاده از الگوریتمهای استاندارد بسیار ایمن تر از نوشتن الگوریتم Encryption توسط شماست، چراکه اون الگوریتمها توسط دانشمندان ریاضی نوشته و آزمایش شده. شما مهندس هستید، نه دانشمند ریاضی! فقط دقت کنید که از الگوریتمهایی که SDL اونها رو ملغی اعلام کرده، برحذر باشید. کلید برخی از این الگوریتمها، طی سالها توسط افراد مختلف در سراسر جهان باز شدن و از اونها هرگز نباید استفاده کرده. MD4 (بعنوان مثال) یکی از اونهاست. در هر حال، وقتی داده های مهم در بانک Encrypt بشن، دیگه اهمیتی نداره که فرد بدخواه بتونه اونها رو ببینه یا نبینه. چون تفاوتی به حالش نخواهد کرد.

6. محیط و چرخه توسعه نرم افزاری خودتون رو از همون ابتدا ایمن کنید. برای این منظور میتونید از SDL و روشهای پیشنهادی M. Howard استفاده کنید.

و احتمالا مسائل دیگه ای که اگر بعدا بخاطر بیارم در موردش خواهم نوست. اما "فرد فضول" و ... وقتی شما میگید فرد فضول، و براش بیشترین دسترسی رو قائل هستید، من زبونم بند میاد. چون Elevation of Privilege آخرین نقطه در STRIDE هستش (فرصت توضیح اینو ندارم، لطفا خودتون روی اینترنت در این مورد بخونید).

اما در هر حال، شما می تونید با Auditing بخشی از این نگرانی رو رفع کنید. اما این فرد فضول، قاعدتا مالک این نرم افزار هستش و هرگونه خرابکاری در این نرم افزار، خرابکاری در سازمانی که در اون کار میکنه میتونه تلقی بشه و عملا "آسیب بخودی" محسوب میشه. شما باید Backup های مداومی از بانک بگیرید (جدا از مواردی که در بالا به اونها اشاره کردم) تا در هنگام لزوم بتونید سیستم رو با چند تا click ساده، به "آخرین وضعیت کاری مناسب" برگردونید. اگر مشکلی برای سیستم از جانب این کاربر بدخواه پیش بیاد، شما می تونید اونو با روشهای مکانیزه تشخیص و Log کنید. اما دقت کنید، اگر این فرد اجازه دسترسی به این سیستم رو داره، طوریکه میتونه توی بانک بطور مستقیم دخل و تصرف داشته باشه (یعنی Full privileged هستش)، دیگه از دست شما کاری بر نمیاد. عین این میمونه که من کلید خونه ام رو به شما که (فکر میکنم) امین من هستید بسپرم و برم سفر. وقتی برگردم ببینم خونه خالی هستش! من به شما اطمینان دارم که کلید رو در وهله اول بهتون داده ام، که اگر نداشتم، نباید میدادم. تو بدترین حالت، شما میتونید بانک رو به سیستم دیگه ای انتقال بدید، میتونید اونو روی یک Virtual Machine روی سیستم کاربر (پشت پرده) اجرا کنید و ...

روشهای متنوعی برای چنین کارهایی وجود داره، اما عموما، سطح دسترسی ها و سمت افراد مسئول در بخشهای مختلف یک سازمان، و قوانین حاکم بر سازمانی که برنامه رو در اونجا نصب می کنید، جلوی رسیدن به چنین راه حل هایی رو میگیره.

امیدوارم که وقتی گفتید "فضول"، منظورتون افراد "آموزش ندیده" نباشه. آموزش بخش مهمی از این چرخه هستش، که هرگز نباید نادیده گرفته بشه.

موفق باشید.