فایل ورد کامل مقاله امنیت پایگاه‌های داده سروری؛ تحلیل علمی تهدیدات، راهکارها و فناوری‌های حفاظت اطلاعات

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

 فایل ورد کامل مقاله امنیت پایگاه‌های داده سروری؛ تحلیل علمی تهدیدات، راهکارها و فناوری‌های حفاظت اطلاعات دارای ۴۳ صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

فایل ورد فایل ورد کامل مقاله امنیت پایگاه‌های داده سروری؛ تحلیل علمی تهدیدات، راهکارها و فناوری‌های حفاظت اطلاعات  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد.

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

بخشی از متن فایل ورد کامل مقاله امنیت پایگاه‌های داده سروری؛ تحلیل علمی تهدیدات، راهکارها و فناوری‌های حفاظت اطلاعات :

امنیت در پایگاههای داده ای (سرور)
مقدمه
با گسترش استفاده از تکنولوژی وب و توسعه برنامه‌هایی که برای کارکرد درین بستر تولید میشوند مباحث مربوط به امنیت پایگاههای داده ای بعد جدیدتری پیدا کرده اند. هر چند از آغاز پیداش پایگاههای داده همواره امنیت و تامین آن یک دغدغه مهم و پیاده سازی مناسب و کارای آن یک خصوصیت بنیادی در پایگاههای داده بوده است اما بهر روی بحث امنیت (Security)همواره در سایه مقولاتی همچون عملکرد مناسب (Functionality) ، کارایی (Performance) و قابلیت اطمینان (Reliability) قرار میگرفت. به عبارتی هنوز هم چندان عجیب نیست اگر ببینیم یک برنامه رده سازمانی (Enterprise Level) با تعداد زیادی Client بدون هیچگونه ملاحظه امنیتی تولید شده و مورد استفاده باشد. حتی میتوان درین زمینه مثالهای جالبتری یافت. اغلب برنامه‌های Client-Server با نام کاربری sa(System Administrator) به پایگاههای داده متصل میشوند. از دید امنیتی این مطلب یک فاجعه محسوب میشود. هیچ تغییر و یا خرابکاری ای قابل ردیابی نیست، همه کاربران به همه اطلاعات دسترسی دارند و الی آخر.

آنچه ذکر شد ، در واقع تصویری از وضعیت جاری بود، که باید از دو منظر نگریسته شود: عدم وجود مکانیزمهای امنیتی مناسب و نیز در صورت وجود چنین مکانیزمهایی عدم بهره گیری صحیح ازانها یا نداشتن سیاست امنیتی مطلوب.
این وضعیت شاید در دنیای برنامه‌های مبتنی بر تکنولوژی‌های Mainframe یا Client-Server قابل تحمل بود اما در شرایط فعلی که برنامه‌ها با سرعت زیادی به سمت بهره گیری از بستر وب میروند ادامه این روند فاجعه بار است. در حال حاضر دیگر کاربران یک برنامه به صورت بالقوه تنها کارمندان یک سازمان نیستند. هر فردی میتواند به سادگی باز کردن یک مرورگر وب به پایگاه داده شما متصل شود و مطمئن باشید اگر مکانیزمهای امنیتی را رعایت نکرده باشید ، حذف تمامی داده‌های شما حتس از عهده یک نفوذگر عادی هم بر می‌آید.

اجازه دهید یک فرض اساسی را مطرح کنیم. مدیران IT یک سازمان بر دو دسته اند: مدیران نوگرایی که به صورت داوطلبانه سازمان را به سمت ارائه خدمات عمومی و گسترده هدایت میکنند و به همین دلیل تکنولوژی وب را به عنوان تنها بستر موجود برای ارائه این خدمات میپذیرند و مدیران سنتی محافظه کاری که قابلیت اطمینان و کارایی سیستم جاری را تحت هیچ شرایطی حاضر نیستند در معرض خطر قرار دهند. وب از نظر این گروه دوم کماکان یک تکنولوژی مشکوک غیر قابل اطمینان است. در واقع دلایل فنی این گروه دوم هنوز هم چشمگیر و قابل اعتناست، به خصوص گروهی که از mainframe‌ها صحبت میکنند. قابلیت اطمینان ۰۹۹۹۹۹ هنوز هم در دنیای غیر Mainframe یک رویاست.

زمانی که بحث امنیت در بستر وب مطرح میشود به صورت عمده سه جزء زیر مد نظر است:
• امنیت سرور(Server Security)
• امنیت در تصدیق اعتبار(Authentication Security)
• امنیت محاوره(Session Security)
در ادامه نگاهی به جزئیات هریک از اجزای این دسته بندی خواهیم داشت.

شاید بخش عمده امنیت سرور مربوط به مدیر شبکه و نیز کارشناس امنیت اطلاعات باشد. ازین نظر DBA مسئولیت چندانی ندارد ، البته این به شرطی ست که قبلا متخصص امنیت شبکه مکانیزمهای امنیتی مناسب را جهت سرور پیش بینی کرده باشد. این مکانیزمها محدوده وسیعی از ابزارها و راه حلهای امنیتی را در بر میگیرد: فایروالها ، تشخیصگرهای نفوذ (Intrusion Detectors) ، ضد ویروسها ، ; از جمله ابزارها هستند . معماری امن شبکه و لحاظ کردن مسائل امنیتی درین معماری نیز میتواند حائز اهمیت باشد. تمامی این مباحث زیر مجموعه بحث امنیت شبکه می‌باشند که در بخش آتی به صورت خیلی مختصر به آن اشاره خواهیم کرد:

معماری امن شبکه با نگاه به پایگاه داده
الف. در نظر گرفتن سخت افزار جداگانه جهت سرور وب و سرور پایگاه داده
بسیاری از سرویسهای کنونی وب و حتی شبکه‌های داخلی (Intranet) به گونه ای طراحی شده‌اند که سرور اصلی پایگاه داده (Back End Server) را روی همان سروری در نظر میگیرند که سرویس وب روی آن راه اندازی شده است. البته برای این کار چندین توجیه وجود دارد :
• توجیه اقتصادی: در نظر گرفتن هر دو سرویس بر روی یک ماشین از جهت هزینه کل سازمان یک صرفه جویی محسوب میشود. باید توجه داشت که برای ارایه هر دوی این خدمات ماشینهای با قدرت پردازش بالا باید در نظر گرفته شوند.

• توجیه فنی: عده ای برین عقیده‌اند که ارائه این دو خدمت بر روی یک ماشین سبب بهبود کلی کارایی میشود. استدلال اصلی محدودیت سرعت بر روی شبکه است. این استدلال نیز توجیه چندانی ندارد زیرا حداقل سرعت شبکه‌های محلی فعلی ۱۰۰Mb/s است که بسیار بالاتر از حداکثر سرعت شبکه‌های WAN در حال حاضر است.

بنابراین از دو توجیه بالا تنها استدلال مبتنی بر صرفه جویی اقتصادی کماکان میتواتند مطرح باشد. اما خطرات اجرای این دو سرویس بر روی یک مکاشین به حدی ست که بهتر است سازمان به جای پذیرش این ریسکها، هزینه اضافی مربوطه را متحمل شود. تا کنون روشهای متعددی برای نفوذ به سرورهای وب طراحی و اجرا شده است. بسیاری از ویروسهای کامپیوتری و نیز کرمهای اینترنتی (Code Redو Nimda) نیز اساسا بر پایه همین ضعفها عمل میکنند. صرف نظر از نوع سرور وبی که در نظر میگیرید (Apache،IIS یا هر سرور دیگر) همیشه باید این احتمال را بدهید که در صورت وجود یک شکاف امنیتی در سرور مربوطه، شما در مجموع کمترین ضرر را متحمل شوید.

جدا کردن فیزیکی دو سرور وب و پایگاه داده این امر را تا حدی (دقت کنید که فقط تا حدی و نه به طور کامل) برای شما تضمین میکند که حتی اگر نفوذگری توانست اختیارات مدیر سیستم مربوط به سرور وب را به دست بیاورد نتواند به سادگی به اطلاعات موجود روی پایگاه داده نیز دست یابد.
ب. قرار ندادن پایگاه داده در DMZ:

در صورتی که از یک معماری امن برای پیاده سازی شبکه خود استفاده کرده باشید به احتمال زیاد شبکه شما دارای یک بخش DMZ(Don’t Militarized Zone) خواهد بود. معمولا ارائه دهندگان خدمات عمومی را درین بخش از شبکه قرار میدهند. بعنوان مثال سرورهای وب، سرورهای میل ; که همگی جهت خدمات عمومی بکار میروند درین بخش از شبکه قرار دارند.

ایده عمومی داشتن یک بخش DMZ ساده ست: سرورهایی که خدمات عمومی بیرون سازمانی ارایه میدهند نیازمند سطح کمتری از امنیت هستند. در واقع همه میتوانند به آنها دسترسی داشته باشند. این دسترسی همگانی به هیچ وجه لازم نیست در مورد تمامی منابع شبکه اعمال شود. بنابرین منابع عمومی شبکه را در بخشی از شبکه قرار میدهند که حساسیت امنیتی کمتری نسبت به آن وجود دارد. این همان بخش DMZ است. با توجه به مطالب بالا بسیار بدیهی به نظر میرسد سرور پایگاه داده را باید در همان بخش DMZ قرار دهیم زیرا که عموما این سرور نیز مسئولیت ارائه خدمات همگانی را بعهده دارد. اما قضیه در باره سرور پایگاه داده تا حدی متفاوت است. این سرور گرچه خدمات همگانی نیز عرضه میکند اما تنها بخشی از داده‌های آن ممکن است جنبه همگانی داشته باشد در حالی که عمده آن در اغلب اوقات سری ست. بعنوان مثال سروری که اطلاعات مربوط به کارت اعتباری افراد را نگهداری میکند از اهمیت فوق العاده ای برخوردار است و هرگونه دسترسی به کل داده‌های آن میتواند فاجعه بار باشد.

بنابراین بر خلاف دید اولیه به این نتیجه میرسیم که پایگاه داده نمیتواند و نباید که در بخش DMZ قرار گیرد. اما راهکار جداسازی آن ازین بخش چیست؟

راه حل ایده آل برای این جداسازی به شرح زیر است: به صورت عام از یک فایروال اصلی برای ایمنی کل شبکه و جداسازی آن از دنیای بیرون استفاده میشود. این فایروال در قسمت بیرونی DMZ قرار دارد و دارای قواعد خاص خود است. بدلایلی که در بخش پیش ذکر شد که کلا عبارت بود از نیاز به ارائه خدمات عمومی ،این فایروال نمیتواند کل ترافیک ورودی را محدود کند و ناچار است یک سیاست (Policy) حداکثری را اعمال کند.

اما در داخل خود شبکه ، مابیت LAN داخلی و DMZ از فایروال دومی استفاده میشود. این فایروال دوم در حالت ایده آل تمامی ترافیک ورودی را سد میکند بجز ترافیک ورودی از وب سرور به پایگاه داده. با این تمهید خاص هم پچایگاه داده خدمات عمومی خود را ارائه میدهد و هم دستیابی عموم را به آن سد کرده ایم. درین صورت یک نفوذ گر حتی پس ازینکه کنترل کامل سرور وب را در اختیار گرفت ناچار است از قواعد سختگیرانه فایروال دوم نیز عبور کند و تازه پس ازان باید بتواند به سرور پایگاه داده نیز نفوذ کند که انجام این هر دو کار بسیار دشوار میباشد و ریسک چنین شبکه ای عملا پایین می‌باشد.

اما شاید در مقابل روش ما استدلالی اینچنین ارائه شود: میتوان تنها با استفاده از یک فایروال امنیت را تامین کرد. روش آنهم اینست که برای سرورهای پایگاه داده از IP مجازی استفاده کنیم. در واقع این سرورها پشت یک NAT قرار داشته باشند. درین صورت نفوذگر اساسا از وجود پایگاه داده خبر ندارد تا بخواهد به آن نفوذ کند. این استدلال یک ابراد عمده دارد و آنهم اینست که اگر نفوذ گر بتواند کنترل سرور وب را در اختیار بگیرد عملا در همان شبکه ای قرار گرفته است که سرور پایگاه داده دران قرار دارد و دارای همان رنج IP میشود. بنابراین پس ازینکار در واقع تمهید قبلی ما بلااثر میشود و نفوذ گر میتواند بسادگی مانند یک کاربر داخلی شبکه ما عمل کند.

حال که استدلالات فوق را پذیرفته ایم میتوانیم کمی ایده آل تر باشیم و شبکه را ایمن تر کنیم. فرض کنید که یک نفوذگر بتواند از لایه اول امنیتی شما عبور کرده وارد DMZ شود. اگر این نفوذ به دلیل نقص قواعد امنیتی فایروال شماره یک باشد احتمال نفوذ همین شخص به لایه دوم بسیار پایین است. اما اگر این نفوذ به دلیل وجود شکاف امنیتی خاصی بر روی فایروال باشد چطور؟ فرض کنید به عنوان مثال هردو فایروال شما Check Point است. آنوقت نفوذگر بهمان سادگی که از لایه اول عبور کرده از لایه دوم امنیتی شما نیز خواهد گذشت چون هر دو فایروال ما از یک نوع است و طبیعتا شکاف امنیتی هردو یکسان است. بنابراین میتوان پیشنهاد داد که فرضا اگر فایروال لاه اول شما Check Point است در لایه دوم بهتر است از PIX استفاده کنید. این مطلب باعث امنیت بالاتر شبکه شما خواهد شد.

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

راه حل دیگری که میتوان برای جداسازی بخش امن شبکه ارائه داد استفاده از بیش از یک کارت شبکه در فایروال است (شکل ۲)

همانطور که مشخص است درین روش توسط یک فایروال، DMZ از بخش امن شبکه جداسازی میشود. تنها ترافیکی که حق عبور از اینترفیس اول (eth1) به اینترفیس امن (eth2) را دارد ترافیک ورودی از وب سرور به سرور پایگاه داده میباشد. این روش بسیار ارزان تر از روش قبلی ست اما مشخصا امنیت آن در حد امنیت روش قبل نیست و علاوه برآن ممکن است فایروال موجود ما عملا از چندین کارت شبکه پشتیبانی نکند.

علاوه بر دو راهی که در فوق برای جداسازی پایگاه داده از مابقی شبکه ارائه دادیم راه حل سومی هم وجود دارد: اینکه اساسا پایگاه داده را از مابقی شبکه جدانکنیم! دقت کنید که با توجه به هزینه و نیز اندازه سازمان ممکن است جداسازی امکان پذیر نباشد و حتی مجبور شویم که این دو سرور را برروی یک ماشین اجرا کنیم. حتی درین صورت نیز بهتر است حداقل کارهایی که جهت ایمنی مضاعف پایگاه داده از دستمان بر می‌آید انجام دهیم. بعنوان مثال میتوانیم از یک فایروال نرم افزاری ارزان قیمت جهت ایمنی بیشتر استفاده کنیم. بهر حال این راه حل توصیه نمیشود مگر در شرایط اجبار.

رمز نگاری اطلاعات مابین سرور وب و سرور پایگاه داده
برای جلوگیری از سرقت اطلاعات در بین راه(Sniffing) عموما از روشهای رمز نگاری استفاده میشود. متداول ترین روش تحت وب برای انجام این منظور استفاده از پروتکل SSL است. عموم اطلاعات امن که بر روی اینترنت منتقل میشوند از همین پروتکل استفاده میکنند . بعنوان مثال انتقال اطلاعات شناسایی با سرورهای معروف ایمیل، انتقال اطلاعات مربوط به کارت اعتباری و غیره.

تا بدینجا این پروتکل که اغلب سرورهای وب و نیز مرورگرها ازان پشتیبانی میکنند سطحی از امنیت را تامین میکند. اما آیا همین کافی ست؟
اغلب این اشتباه پیش می‌آید که همین سطح از رمز نگاری را در مقابل حمله Sniffing کافی میدانند. باید دقت کرد که SSL به صورت عام تنها برای رمزنگاری اطلاعات مابین Client و سرور وب به کار میرود و به صورت عادی اطلاعات مابین وب سرور و سرور پایگاه داده به صورت عادی و بدون رمزنگاری (Plain Text) منتقل میشوند. بنابراین حتی اگر همه جوانب را در شبکه بیرونی رعایت کرده باشیم، یک نفوذگر داخلی به سادگی میتواند اطلاعات در حال انتقال مابین این دو سرور را شنود کند. این مطلب زمانی بسیار جدی میشود که بدانیم بر اساس داده‌های موجود، بالاتر از ۶۰ حملات موجود حملات درون سازمانی می‌باشد.
چاره کار استفاده از یک روش رمز نگاری مابین سرور وب و سرور پایگاه داده است. اغلب سرور‌های پایگاه داده امروزه از SSL حمایت میکنند. MS SQL Server2000 ، Oracle،Sybase ازین جمله اند. البته استفاده از SSL برای ارتباط مابین این دو سرور لازمه اش اینست که برنامه اصلی شما (Web Application) با همین ملاحظه طراحی و پیاده سازی شده باشد.

اما در صورتی که برنامه شما از قبل موجود باشد یا از SSL پشتیبانی نکند یا به هر صورت شما مایل به ایجاد هزینه اضافی نباشید چه؟ آیا راه حل دیگری برای رمزنگاری مابین دو سرور وجود دارد؟ خوشبختانه چنین راه حلی وجود دارد: استفاده از SSH یا یک برنامه مشابه.

اصولا SSH برنامه ای شبیه Telnet است اما نسخه امن آن. یکی از قابلیتهای SSH ایجاد یک تونل امن است. به این صورت که میتوان برنامه SSH را به گونه ای اجرا کرد که بر روی یک پورت شنود کند کل اطلاعات آن را رمز کرده به کامپیوتر مقصد ارسال کند و آنجا پس از تبدیل به حالت عادی به پورت مقصد تحویل دهد. با استفاده از این روش (SSH Port Forwarding) یک تونل امن به صورت شفاف مابین دو سرور ایجاد شده است(شکل ۳).

مزیت استفاده ازین روش اینست که نیاز به هیچگونه تغییری در سرورها و یا برنامه‌ها ندارد و تنها توسط چند خط دستور قابل اجراست.
د. عدم استفاده از Hub و بهره گیری از Switch

به صورت عادی زمانی که از Hub استفاده میکنیم تمامی اطلاعات عبوری در هریک از سیستمهای موجود در شبکه داخلی قابل شنود است. یک نفوذ گر معمولی با استفاده از یکی از ابزارهای Sniffing میتواند اینترفیس شبکه با به حالت Promiscuous برده ، تمامی اطلاعات در حال جابجایی بر روی LAN را دریافت کند. البته استفاده از رمز نگاری خطر بالقوه بهره گیری ازین روش را کم میکند اما هیچگاه نمیتوان مطمئن بود که کل اطلاعات رمز نگاری شده است. بنابراین بهتر است حتی المقدور امکان بهره گیری از Sniffing را بر روی شبکه کاهش دهیم. استفاده از سوپیچها به جای‌هاب یکی از روشهای حل این مساله است. با استفاده از سوئیچ در واقع یک مدار مجازی (Virtual Circuit) مابین دو نود در حال مکالمه ایجاد میشود و دیگران به اطلاعات در حال انتقال مابین آن دو دسترسی ندارند.

۲-۶. ارائه امن اطلاعات
از دید کلی امنیت اطلاعات برای ارائه خدمات اطلاع رسانی بر روی وب به صورت عمده دو راه وجود دارد:
• تولید اطلاعات به صورت استاتیک
• تولید اطلاعات به صورت دینامیک

۱-۲-۶. تولید اطلاعات به صورت استاتیک و مسائل امنیتی آن
معمولترین نوع دسترسی به اطلاعات در اینترنت استفاده از صفحات HTML است. هنوز هم بسیاری از متخصصین، این روش در دسترس گذاری اطلاعات (Web Publishing) را به روشهای دیگر ترجیح میدهند. البته دلایل اصلی آنها بیشتر مربوط به سادگی و قابلیت انعطاف این روش است.
درین روش اطلاعات یک بار تولید میشود. تولید اطلاعات (صفحات HTML) میتواند به صورت دستی یا به صورت اتوماتیک توسط برنامه‌های معمولی Client-Server انجام شود. پس از انجام این فاز کلیه اطلاعات بر روی سایت و سرور اصلی قرار میگیرد (Upload).

امنیت این روش به سادگی تامین میشود. کافیست که اشخاص نام فایلهای HTML را ندانند، درین صورت هرگز به آنها دسترسی نخواهند داشت. اینکار با استفاده از مکانیزم ساده ای صورت میگیرد. عموم وب سرورها برای دایرکتوریهای مختلف حق دسترسی تعریف میکنند که یکی ازین حقوق دسترسی حق مشاهده محتویات یک دایرکتوری است. در صورتی که کاربری این حق را نداشته باشد از اسامی فایلها بی خبر خواهد بود و در نتیجه قادر به مشاهده آنها نیست.
استفاده ازین روش مزایا و معایب خاص خود را دارد. مزیت آن امنیت بالاست. در واقع درینجا هیچ ارتباز اکیتیوی با سرور پایگاه داده وجود ندارد. اطلاعات به صورت برون خط (Offline) بر روی سرور وب بارگذاری میشوند و پس ازان هیچ ارتباطی مابین کاربر عادی و چپایگاه داده وجود نخواهد داشت. بدین ترتیب خطر حملات به پایگاه داده کاهش چشمگیری می‌یابد. اما از دیگر سو مدیریت حجم انبوه اطلاعات با استفاده ازین روش بسیار دشوار میباشد . ضمن اینکه قابلیت انعطاف روش نیز بسیار محدود است. در واقع زمانی که ازین روش استفاده میکنیم هدف اصلی خدمت رسانی و سهولت استفاده را قربانی امنیت کرده ایم.
۲-۲-۶. تولید اطلاعات به صورت دینامیک

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

برای پیاده سازی این روش طیف وسیعی از تکنولوژیها وجود دارد. ASP،JSP،PHP،CGI،ISAPI; و چندین روش دیگری که عم۵ما حول همین تولید دینامیک اطلاعات إر محیط وب طراحی شده اند. هریک از این زبانها و روشها خود موضوع بحث مفصل و جداگانه ای است اما از دید بحث حاضر چند نکته مهم را باید مد نظر داشت:

• تا کنون شکافهای جدی امنیتی در مورد هر یک ازین روشها شناخته شده إست و با وجود این حل اغلب آنها هنوز هم هیچکدام آنها امنیت بالایی را به تنهایی تضمین نمیکنند.
• با وجود نکته بالا، چون هدف اصلی ارائه خدمت یاسرویس است در بسیاری موارد چاره ای بجز استفاده از یکی از این روشها نداریم.
• هنگام انتخإب هر یک از این روشها باید ملاحظات امنیتی مربوط به ابزارهای مدیریت وتوسعه را نیز لحاظ کنیم.
طی بخش گذشته عموما توجه ما معطوف به این مطلب بود که چگونه جلوی دستیابی افراد غیر مجاز به سیستم و اطلاعات گرفته شود. اما هیچ گاه به این مطلب اشاره نکردیم که مجاز یا غیر مجاز بودن افراد را چگونه تشخیص میدهیم. در واقع روش شناسایی افراد در یک سیستم امن چگونه میتواند باشد.
ابتدایی ترین روشی که درین زمینه میتوان در نظر گرفت تصدیق اعتبار ساده بر حسب نام کاربری و کلمه عبور است. گرچه پیاده سازی این روش سنتی بسیار ساده است اما امنیتی هم که تامین میکند حداقل امنیت ممکن است. درین روش کاربر یکبار در سیستم شناسایی میشود و پس ازان اطلاعات به صورت عادی بر روی شبکه جریان می‌یابد. مشکلات این روش را میتوان به صورت زیر خلاصه کرد:

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

رمزنگاری در پروتکل‌های انتقال
تمرکز بیشتر روش‌های امنیت انتقال فایل بر اساس رمزنگاری دیتا در طول انتقال از طریق شبکه‌های عمومی مانند اینترنت است. دیتایی که در حال انتقال بین سازمانهاست بوضوح در معرض خطر ربوده ‌شدن در هر کدام از محلها قرار دارد. – مثلا در شبکه‌های محلی برای هر یک از طرفین یا مرزهای Internet-LAN که سرویس‌دهندگان‌اینترنت از طریق آنها مسیر دیتا را تا مقصد نهایی مشخص می‌کنند. حساسیت دیتا ممکن است بسیار متغییر باشد، زیرا دیتای انتقالی ممکن است بهر شکلی از رکوردهای مالی بسته‌بندی شده تا تراکنش‌های مستقیم باشند. در بعضی موارد، ممکن است علاوه بر محافظت دیتا روی اینترنت، نیاز به محافظت دیتا روی LAN نیز باشد. مشخصاً، محافظت از دیتا در مقابل حملات LAN مستلزم رمزنگاری دیتای انتقالی روی خود LAN است. به این ترتیب، بهرحال، نیاز به بسط امنیت تا برنامه‌هایی است که خود دیتا را تولید و مدیریت می‌کنند، و تنها اطمینان به راه‌حلهای محیطی کفایت نمی‌کند و به این ترتیب بر پیچیدگی مسأله امنیت افزوده می‌شود.

پروتکل‌ها
• اگرچه ثابت‌شده است که رمزنگاری راه‌حل بدیهی مسائل محرمانگی است، اما سردرگمی در مورد دو نوع رمزنگاری (برنامه در مقابل شبکه) همچنان وجود دارد و بدلیل وجود پروتکلهای ارتباطی گوناگون است که نیازهای تعامل بیشتر آشکار می‌شود. (مانند IPSec ، S/MIME، SSL و TLS) اگرچه این پروتکلها قول تعامل را می‌دهند، اما تعامل کامل بدلیل مستقل بودن محصولات پروتکلها در حال حاضر وجود ندارد. آزمایشهایی در حال حاضر در حال انجام هستند که به حل شدن این مسائل کمک می‌کنند، اما کاربران باید مطمئن شوند که تعامل بین محصول انتخابیشان و محصولات سایر شرکای تجاری امری تثبیت شده است. پروتکل‌های ساده‌تر (SSL/TLS، IPSec و تا حدی پایین‌تر S/MIME ) عموماً مسائل کمتری از نظر تعامل دارند.

پروتکل‌های رمزنگاری انتقال
• با ترکیب توانایی‌ها برای تایید هویت توسط رمزنگاری متقارن و نامتقارن برای ممکن ساختن ارتباطات تاییدشده و رمزشده، این پروتکلها پایه‌های امنیت را فراهم می‌کنند. تقربیاً تمام پروتکلها نیاز‌های جامعیت را پشتیبانی می‌کنند به طوری که محتویات ارتباطات نمی‌توانند تغییر یابند، اما بیشتر آنها از Non-Repudiation پشتیبانی نمی‌کنند و به این ترتیب امکان ایجاد رکوردهای پایداری را که هویت منبع را به محتوای پیام پیوند می‌دهند، ندارند.
• به این چند پروتکل به طور مختصر اشاره می‌شود:

• SSL
• تکنولوژی SSL (Secure Socket Layer) اساس World Wide Web امن را تشکیل می‌دهد. SSL که در مرورگرهای وب کاملاً جاافتاده است، توسط بسیاری از سازمانها برای رمزنگاری تراکنش‌های وبی خود و انتقال فایل استفاده می‌شود. بعلاوه SSL بصورت روزافزون بعنوان یک مکانیسم امنیت در تلاقی با پروتکلهای پرشمار دیگر استفاده می‌شود و بهمین ترتیب ابزاری برای ارتباط سروربه‌سرور امن است. SSL ارتباطات رمزشده و بشکل آغازین خود تایید هویت سرور از طریق استفاده از گواهی را (در حالت کلاینت‌به‌سرور) پشتیبانی می‌کند. کاربران اغلب برای استفاده از برنامه‌ها از طریق کلمه عبور تایید هویت می‌شوند، و با پیشرفت SSL استاندارد (مثلا SSL V.3.0) تایید هویت کلاینت از طریق گواهی به این پروتکل اضافه شده است.

• *برای FT (انتقال فایل): ابزار FT اغلب از SSL برای انتقال فایل در یکی از دو حالت استفاده می‌کنند. اولی، مد کلاینت‌به‌سرور است که کاربر را قادر می‌سازد، در حالیکه در حال استفاده از یک مرورگر وب استاندارد است مستندات را از یک سرور دریافت یا آنها را به سرور منتقل کند. که این قابلیت نیاز به نرم‌افزار مختص انتقال در کلاینت را برطرف می‌سازد و بسیار راحت است، اما اغلب فاقد بعضی ویژگیهای پیشرفته مانند نقاط آغاز مجدد و انتقالهای زمانبندی‌شده است که سازمانها نیاز دارند. SSL همچنین می‌تواند برای اتصالات سروربه‌سرور امن – برای مثال، در اتصال با FTP و سایر پروتکلها – مورد استفاده قرار گیرد.

TLS
• TLS (Transport Layer Security)، جانشین SSL، برپایه SSL3.0 بنا شده است، اما به کاربران یک انتخاب کلید عمومی و الگوریتمهای Hashing می‌دهد. (الگوریتمهای Hashing فانکشن‌های یک‌طرفه‌ای برای حفظ جامعیت پیامها هستند و توسط بیشتر پروتکلها استفاده می‌شوند.) اگرچه TLS و SSL تعامل ندارند، اما چنانچه یکی از طرفین ارتباط TLS را پشتیبانی نکند، ارتباط با پروتکل SSL3.0 برقرار خواهد شد. بیشتر مزایا و معایب SSL به TLS هم منتقل می‌شود، و معمولا وجه تمایز خاصی وجود ندارد، و از همه نسخه‌ها به عنوان SSL یاد می‌شود.
S/MIME
• S/MIME ( Secure Multipurpose Internet Mail Extention) که اختصاصاً برای پیام‌رسانی ذخیره-و-ارسال طراحی شده است، بعنوان استاندارد امنیت ایمیل برتر شناخته شده است. مانند بیشتر پروتکل‌های رمزنگاری (مثلا SSL ، TLS و IPSec)، S/MIME با رمزنگاری تنها سروکار ندارد. بهرحال، علاوه بر تصدیق هویت کاربران و ایمن‌سازی جامعیت پیامها (برای مثال مانند آنچه SSL انجام می‌دهد)، S/MIME توسط امضای دیجیتال، رکوردهای پایداری از صحت پیامها ایجاد می‌کند (ضمانت هویت فرستنده چنانچه به محتوای پیام مشخصی مرتبط شده). این عمل باعث می‌شود فرستنده پیام نتواند ارسال آن‌را انکار کند.
FT :
• سیستم‌های ایمیل رمزشده (با استفاده از S/MIME) می‌توانند برای ارسال فایل‌های کوچک استفاده شوند (محدودیت حجم فایل بخاطر داشتن محدودیت حجم فایل در بیشتر سرورهای ایمیل است)، ولی S/MIME کلاً می‌تواند برای انتقال فایل‌های بزرگتر توسط پروتکلهای انتقال فایل استفاده شود.
SSH
• SSH (Secure Shell) هم یک برنامه و یک پروتکل شبکه بمنظور وارد شدن و اجرای فرمانهایی در یک کامپیوتر دیگر است. به این منظور ایجاد شد تا یک جایگزین رمز‌شده امن برای دسترسی‌های ناامن به کامپیوترهای دیگر مثلا rlogin یا telnet باشد. نسخه بعدی این پروتکل تحت نام SSH2 با قابلیتهایی برای انتقال فایل رمزشده از طریق لینک‌های SSH منتشر شد.
• *برای FT :
• SSH‌ می تواند برای پشتیبانی انتقال فایل رمزشده (به شکل SFTP) استفاده شود اما طبیعت خط فرمان بودن آن به این معنی است که بیشتر توسط مدیران سیستمها برای ارسال درون سازمان استفاده می‌شود تا برای انتقال فایل تجاری. بعلاوه استفاده از SSH نیاز به نرم‌افزار یا سیستم عاملهای سازگار با SSH در دو طرف اتصال دارد، که به این ترتیب SSH برای سرور‌به‌سرور انجام می‌گیرد.

آیا می توان به برنامه های رمز نگاری اعتماد کرد؟
عیوب رمزنگار در gnu
امروزه از رمزنگاری در برنامه های بسیاری استفاده می شود اما از کجا باید بدانیم که آنچه به عنوان رمزنگاری پیاده سازی شده، رمزنگاری مناسب است؟ تنها راه روشن شدن این مطلب مهندسی معکوس می‌باشد. همچنین روند تاریخی نرم‌افزارهای رمزنگاری نشان می‌دهد که رمزنگاری با عملکرد بد، بسیار رایج‌تر از رمزنگاری با عملکرد خوب می‌باشد. بنابراین به نظر می‌رسد که نرم‌افزارهای متن باز راه‌حل مناسبی می‌باشند. اما این واقعیت که کد متن خواندنی است به این معنا نیست که توسط مجربین امنیت خوانده می‌شود. در این مقاله، برنامه رمزنگاری پست الکترونیکی امن بررسی می‌گردد.

GNU Privacy Guard، GPG)یا (GnuPG نسخه معروف متن باز رایگان نرم‌افزار PGP می‌باشد و مشابه استاندارد OpenPGP است و در بیشتر توزیعهای GNU/Linux مانند, MandrakeSoft ,Debian Red Hat و SuSE بکار می‌رود. ما اجزاء کد متنی v1.2.3 GPG را بررسی کرده و چندین عیب رمزنگاری در آن یافته‌ایم. جدی‌ترین عیب GPG به شرح ذیل می‌باشد.

کلید خصوصی امضاکننده پیام به روش ELGamal (تولید شده توسط مجری)، در کمتر از یک ثانیه، بر روی PC بازیابی می‌گردد. اخیراً امضاهای ELGamalو نشانه ELGamal + کلیدهای رمزنگاری از GPG حذف شده‌اند. خوشبختانه، ELGamal گزینه پیش فرض GPG برای کلیدهای امضا نمی‌باشد. کلمات کلیدی: رمزنگاری کلید عمومی، OpenPGP, GPG, GnuPG، آنالیز رمز RSA، ELGamal ، پیاده‌سازی.

در دنیـــای رمزنگاری، استانـــداردهای متعددی چـــــون [۲۰]RSA PKCS ،[۸]NESSIE , [14]IEE P1363 [15]CRYPTREC, و … وجود دارد و با وجود چنین استانداردهایی ممکن است به نظر برسد که رمزنگاری خوب بسیار است. اما همانگونه که استفاده از رمزنگاری گسترده‌تر می‌شود چگونه می توان اطمینان داشت که رمزنگاری پیاده‌سازی شده در دنیای واقعی، رمزنگاری مناسب است. خط جداکننده بین رمزنگاری خوب و بد بسیار باریک می‌باشد. [۲۱,۲,۴] تنها راه تشخیص نحوه عملکرد نرم‌افزارهای رمزنگاری، مهندسی معکوس است.

مثلاً نرم‌افزار رمزنگاری را در نظر بگیرید که RSA 1024 بیتی و AES 128 بیتی را پیاده‌سازی کرده است. این ویژگیها، اطلاعات زیادی درباره امنیت واقعی رمزنگاری بیان نمی‌کند. در این زمینه سوالات متعددی مطرح است. از کدام RSA استفاده شده است؟ آیا RSA همان نوعی است که در کتابها تشریح شده [۵](با Zero-padding). آیا AES، ۱۲۸ بیتی با نمای عمومی ۳ رمزنگاری شده است؟ آیا کلیدهای خصوصی با مولدهای عددی شبه تصادفی ضعیف مانند نسخه‌های قدیمی Netscape تولید شده‌اند [۹]؟ چه کسی می‌داند که آیا واقعاً RSA-OAEP [21]پیاده‌سازی شده است ؟ با بررسی تاریخچه نرم‌افزارهای رمزنگاری، متاسفانه به نظر می‌رسد که رمزنگاری بد بسیار رایج است. [۱۲,۲۸] بنابراین به نظر می‌رسد که نرم‌افزارهای متن باز راه حل مناسبی می‌باشند. اما این واقعیت که کد متنی قابل خواندن است، بدین معنا نیست که توسط مجربین

رمزنگاری خوانده می‌شود. پست‌الکترونیکی امن، معروفترین تکنولوژی نرم‌افزاری استفاده شده در اینترنت می‌باشد[۱] و به کاربران امکان احراز اصالت ویا محرمانگی پست الکترونیکی را می‌دهد. پست الکترونیکی امن، در اوایل دهه ۹۰ با ظهور نرم‌افزارPretty Good Privacy(PGP) معروف گردید[۲۷]. PGP توسط Phil Zimmermann در آمریکا ایجاد شد. به دلیل محدودیتهای سخت صدور نرم‌افزارهای رمزنگاری و سایر قوانین آمریکا در گذشته، PGP برای نواحی خارج از آمریکا بسیار نامناسب بود.[۱۰] GNU Privacy Guard (GunPG یا GPG) در اواخر دهه ۹۰ برای رفع سوالات مطرح در PGP ایجاد گردید. GPG، پیاده‌سازی کاملی از OpenPGP [26] است و استانداردی می‌باشد که PGP را گسترش داده است. GPG با گواهینامه عمومی GNU GPL))) GNU General Public License) و به صورت رایگان منتشر گردید. کد کامل متنی GPG موجود است[۱۰] و جایگزین رایگان PGP می‌باشد. وزارت اقتصاد و تکنولوژی فدرال آلمان پایه‌گذار گسترش بیشتر GPG بود. GPG پایه کاربری بسیار مناسبی دارد و در بیشتر توزیعات GNU/Linux مانندRedHat ، MandrakeSoft ، SuSE و Debian موجود است. اولین نسخه ایستای GPG در ۷ سپتامبر ۱۹۹۹ منتشر گردید