eshpilen
دوشنبه 09 دی 1392, 08:03 صبح
امنیت مبحث گسترده و پیچیده و ظریفی بید! :لبخند:
طراحی کردن یک سیستم اصولی که از لحاظ تمام پارامترها بهینه باشه، یا اینطور بگیم که در بهینه ترین تعادل ممکن باشه، کار راحتی نیست و نیاز به دانش و کار زیادی داره.
حالا من توی فکر بودم که مثلا میایم IP کاربران رو سمت سرور Log میکنیم. خب این مقاصد امنیتی و غیره داره. ولی همین ذخیره کردن IP کاربر خودش از نظر امنیتی و Privacy میتونه مشکل داشته باشه. فکر کنید مثلا هکری که به سایت و برنامهء ما نفوذ بکنه، IP های مورد استفادهء کاربران ما رو هم بدست میاره؛ و خب این چیز جالبی نیست! نه؟
پس چه باید کرد؟
همینطور ممکنه اطلاعات دیگری رو هم به دلایل امنیتی و غیره ذخیره کنیم. مثلا نام کاربری های وارد شده در لاگین های اشتباه! اینطوری میتونیم بعدا لاگ ها رو بررسی کنیم ببینیم به کدام اکانت ها میخواستن نفوذ کنن، روبات بوده یا آدم و غیره. البته پسوردها رو که فکر نمیکنم به هیچ وجه مجاز باشیم Log کنیم؛ این کار بیش از حد خطرناکه! ولی شاید هم راهی براش باشه.
خب من یه چندتا ایده داره.
یه ایده اینه که ما اینطور اطلاعات رو بصورت رمز شده در دیتابیس ذخیره میکنیم. مثلا IP و نامهای کاربری و اینا رو با AES128 رمز میکنیم.
طبیعتا کلید رمزگذاری باید در خود برنامه در زمان اجرا موجود باشه. بنابراین مثلا اون رو در کد منبع میذاریم.
خب این کارها حداقل یک مقدار امنیت و مانع در سر راه هکرها یا افراد فضول دیگر ایجاد میکنن، ولی مسئله رو بطور اساسی حل نمیکنن، چون بهرحال کلید و داده های رمز شده هردو زیرمجموعهء یک محیط و سرور هستن و هردو میتونن سرقت بشن. ولی مواردی هست که بهرحال این روش مفید باشه. مثلا مواقعی که دیتابیس رو خوندن ولی نتونستن به فایلهای کدمنبع برنامه دسترسی پیدا کنن. یا همچنین از طریق نسخه های بکاپ دیتابیس که معلوم نیست چه زمانی سر از کجا دربیاره.
اما بازم من یه ایده دارم برای موارد خاص با امنیتی از این هم بیشتر.
اون ایده اینه که اطلاعات رو با یک رمزنگاری نامتقارن رمز میکنیم؛ یعنی کلید عمومی روی سرور و در دسترس برنامه ذخیره میشه، بعد باهاش اطلاعات لاگ ها رو قبل از ذخیره رمز میکنیم. کلید خصوصی هم اصلا روی سرور نیست و دست ادمینه. موقعی که ادمین میخواد لاگ ها رو بررسی کنه، این کلید رو به سرور ارسال میکنه (مثلا از طریق آپلود فایل در فرم مخصوصش) و این کلید برای رمزگشایی اطلاعات و دادن اونا به ادمین استفاده میشه، اما هیچوقت بصورت دائمی در سمت سرور ذخیره نمیشه.
خب ما به این شکل امنیت بیشتری بدست میاریم، ولی بازهم امنیت کاملی نیست. باید توجه داشت که ممکنه هکرها مثلا با کار گذاشتن کد مخفی در کدهای ما، موقعی که ادمین به سایت لاگین میکنه و لاگ ها رو میخونه این کلید رو سرقت کنن. ضمنا این کلید احتمالا از کانالهای ناامن عبور میکنه. بنابراین بهتره یا لازمه این کلید فقط برای همین کارها در برنامه باشه و ازش در کاربردهای جدی تری استفاده نشه.
ضمنا یک محدودیتی که این روش داره اینه که فقط برای کاربردهای لاگ و مشاهده توسط ادمین کاربرد داره و نمیشه از این اطلاعات رمز شده در خود برنامه استفاده کرد (مثلا استفاده برای بررسی و تصمیمات امنیتی توسط برنامه) یا برای خود کاربران نمایش داد، چون نمیتونیم کلید رمزگشایی (کلید خصوصی) رو در سمت سرور ذخیره کنیم.
راستی برای امن تر شدن این سیستم میتونیم اصلا بجای اینکه کلید خصوصی رو به سرور ارسال کنیم، لاگ ها رو توسط یک برنامهء دسکتاپ از سرور دریافت کنیم و عملیات رمزگشایی در سمت کلاینت انجام بشه. به این شکل دیگه نیازی نیست که کلید خصوصی از رایانه شخصی ادمین خارج بشه.
نمیدونم شایدم من زیادی حساس باشم! واقعا چرا اینقدر به خودمون زحمت بدیم بخاطر چندرغاز IP هایی که بیشترشون موقتی هستن یا نامهای کاربری وارد شده؟ آیا اونقدر اهمیت داره که بخاطرش این همه پیچیدگی و حجم و کار اضافی برای خودمون و برنامه درست کنیم؟
البته بنده اینکه باید اطلاعات شخصی و حساس کاربران در سمت سرور رو ذخیره نکرده، اگر هم ذخیره میکنیم حتی الامکان بصورت هش شده، و اگر نمیشه حداقل رمز شده، در منبع امنیتی نسبتا معتبری قبلا خونده بودم.
در اون منبع آمده بود که مثلا سوال و پاسخهای امنیتی که مواقعی مثل فراموش کردن پسورد کاربرد دارن رو بصورت Plain text در سرور ذخیره نکنید و بصورت هش شده ذخیره کنید. یعنی دقیقا مثل کاری که برای پسورد میکنیم!
ولی هش کردن اطلاعاتی که بعدا میخوایم خودمون بررسیشون کنیم یا در برنامه دانستن مقدار واقعی اونا نیاز ممکن نیست، بنابراین میشه بجای هش حداقل از رمزگذاری استفاده کرد. تازه هش کردن در بعضی موارد مثل هش کردن چیزهایی مثل IP چندان امن بنظر نمیرسه، چون تعداد IP های ممکن کمه و بنابراین هش اونها باید براحتی قابل Brute-force باشه. البته میتونیم اول هش کنیم و بعد هش رو هم بصورت رمز شده ذخیره کنیم!! یعنی دیگه نهایت محکم کاری که میتونیم بکنیم.
طراحی کردن یک سیستم اصولی که از لحاظ تمام پارامترها بهینه باشه، یا اینطور بگیم که در بهینه ترین تعادل ممکن باشه، کار راحتی نیست و نیاز به دانش و کار زیادی داره.
حالا من توی فکر بودم که مثلا میایم IP کاربران رو سمت سرور Log میکنیم. خب این مقاصد امنیتی و غیره داره. ولی همین ذخیره کردن IP کاربر خودش از نظر امنیتی و Privacy میتونه مشکل داشته باشه. فکر کنید مثلا هکری که به سایت و برنامهء ما نفوذ بکنه، IP های مورد استفادهء کاربران ما رو هم بدست میاره؛ و خب این چیز جالبی نیست! نه؟
پس چه باید کرد؟
همینطور ممکنه اطلاعات دیگری رو هم به دلایل امنیتی و غیره ذخیره کنیم. مثلا نام کاربری های وارد شده در لاگین های اشتباه! اینطوری میتونیم بعدا لاگ ها رو بررسی کنیم ببینیم به کدام اکانت ها میخواستن نفوذ کنن، روبات بوده یا آدم و غیره. البته پسوردها رو که فکر نمیکنم به هیچ وجه مجاز باشیم Log کنیم؛ این کار بیش از حد خطرناکه! ولی شاید هم راهی براش باشه.
خب من یه چندتا ایده داره.
یه ایده اینه که ما اینطور اطلاعات رو بصورت رمز شده در دیتابیس ذخیره میکنیم. مثلا IP و نامهای کاربری و اینا رو با AES128 رمز میکنیم.
طبیعتا کلید رمزگذاری باید در خود برنامه در زمان اجرا موجود باشه. بنابراین مثلا اون رو در کد منبع میذاریم.
خب این کارها حداقل یک مقدار امنیت و مانع در سر راه هکرها یا افراد فضول دیگر ایجاد میکنن، ولی مسئله رو بطور اساسی حل نمیکنن، چون بهرحال کلید و داده های رمز شده هردو زیرمجموعهء یک محیط و سرور هستن و هردو میتونن سرقت بشن. ولی مواردی هست که بهرحال این روش مفید باشه. مثلا مواقعی که دیتابیس رو خوندن ولی نتونستن به فایلهای کدمنبع برنامه دسترسی پیدا کنن. یا همچنین از طریق نسخه های بکاپ دیتابیس که معلوم نیست چه زمانی سر از کجا دربیاره.
اما بازم من یه ایده دارم برای موارد خاص با امنیتی از این هم بیشتر.
اون ایده اینه که اطلاعات رو با یک رمزنگاری نامتقارن رمز میکنیم؛ یعنی کلید عمومی روی سرور و در دسترس برنامه ذخیره میشه، بعد باهاش اطلاعات لاگ ها رو قبل از ذخیره رمز میکنیم. کلید خصوصی هم اصلا روی سرور نیست و دست ادمینه. موقعی که ادمین میخواد لاگ ها رو بررسی کنه، این کلید رو به سرور ارسال میکنه (مثلا از طریق آپلود فایل در فرم مخصوصش) و این کلید برای رمزگشایی اطلاعات و دادن اونا به ادمین استفاده میشه، اما هیچوقت بصورت دائمی در سمت سرور ذخیره نمیشه.
خب ما به این شکل امنیت بیشتری بدست میاریم، ولی بازهم امنیت کاملی نیست. باید توجه داشت که ممکنه هکرها مثلا با کار گذاشتن کد مخفی در کدهای ما، موقعی که ادمین به سایت لاگین میکنه و لاگ ها رو میخونه این کلید رو سرقت کنن. ضمنا این کلید احتمالا از کانالهای ناامن عبور میکنه. بنابراین بهتره یا لازمه این کلید فقط برای همین کارها در برنامه باشه و ازش در کاربردهای جدی تری استفاده نشه.
ضمنا یک محدودیتی که این روش داره اینه که فقط برای کاربردهای لاگ و مشاهده توسط ادمین کاربرد داره و نمیشه از این اطلاعات رمز شده در خود برنامه استفاده کرد (مثلا استفاده برای بررسی و تصمیمات امنیتی توسط برنامه) یا برای خود کاربران نمایش داد، چون نمیتونیم کلید رمزگشایی (کلید خصوصی) رو در سمت سرور ذخیره کنیم.
راستی برای امن تر شدن این سیستم میتونیم اصلا بجای اینکه کلید خصوصی رو به سرور ارسال کنیم، لاگ ها رو توسط یک برنامهء دسکتاپ از سرور دریافت کنیم و عملیات رمزگشایی در سمت کلاینت انجام بشه. به این شکل دیگه نیازی نیست که کلید خصوصی از رایانه شخصی ادمین خارج بشه.
نمیدونم شایدم من زیادی حساس باشم! واقعا چرا اینقدر به خودمون زحمت بدیم بخاطر چندرغاز IP هایی که بیشترشون موقتی هستن یا نامهای کاربری وارد شده؟ آیا اونقدر اهمیت داره که بخاطرش این همه پیچیدگی و حجم و کار اضافی برای خودمون و برنامه درست کنیم؟
البته بنده اینکه باید اطلاعات شخصی و حساس کاربران در سمت سرور رو ذخیره نکرده، اگر هم ذخیره میکنیم حتی الامکان بصورت هش شده، و اگر نمیشه حداقل رمز شده، در منبع امنیتی نسبتا معتبری قبلا خونده بودم.
در اون منبع آمده بود که مثلا سوال و پاسخهای امنیتی که مواقعی مثل فراموش کردن پسورد کاربرد دارن رو بصورت Plain text در سرور ذخیره نکنید و بصورت هش شده ذخیره کنید. یعنی دقیقا مثل کاری که برای پسورد میکنیم!
ولی هش کردن اطلاعاتی که بعدا میخوایم خودمون بررسیشون کنیم یا در برنامه دانستن مقدار واقعی اونا نیاز ممکن نیست، بنابراین میشه بجای هش حداقل از رمزگذاری استفاده کرد. تازه هش کردن در بعضی موارد مثل هش کردن چیزهایی مثل IP چندان امن بنظر نمیرسه، چون تعداد IP های ممکن کمه و بنابراین هش اونها باید براحتی قابل Brute-force باشه. البته میتونیم اول هش کنیم و بعد هش رو هم بصورت رمز شده ذخیره کنیم!! یعنی دیگه نهایت محکم کاری که میتونیم بکنیم.