بخشی از مقاله
چکیده
در این مقاله برای تحلیل مسائل امنیت معماری نرم افزارهای شی گرا که از مفاهیم معمول امنیت استفاده میکند تلاش شده است تا امنیت یک سیستم در دست طراحی ارزیابی شود. سیستمهای شی گرا بر اساس معماری های گوناگون مانند COM، DCOM، CORBA، MVC و Broker است. در فناوری شی گرا جزء اصلی سیستم یک شی است. هر جزء سیستم ریسک خود را در سیستم ایجاد میکند. سیاست های امنیت و ریسک مربوط به این معماری های نرم افزاری میتواند برای این اجزاء مختلف محاسبه شود. ریسک کل میتواند بر اساس عوامل ریسک در معماری و زمینه محاسبه شود. عوامل کوچک ریسک با هم جمع میشوند و ریسک بزرگی در سیستم ها به وجود آورده و میتوانند به آنها آسیب برسانند.
کلمات کلیدی: امنیت، COM، DCOM، CORBA، استراتژی آزمون، ریسک، SDLC
- 1 مقدمه
نرم افزار یک تجارت تریلیون دلاری است و مقدار تلاش و زمانی که برای توسعه نرم افزار صرف میشود بسیار بزرگ است. به هنگام توسعه نرم-افزار معماری های متفاوت برای توسعه استفاده میشود و امنیت یکی از نگرانی های اصلی در اجزای نرم افزار است. مسائل مربوط به امنیت باید در فازهای اولیه توسعه حل شود و هزینههای صرف شده برای از بین بردن ایرادها در صورتی که در سطح معماری تشخیص داده شوند مینیمم است.[3] اگر توسعه نرم افزار در فاز کد نویسی باشد درک بیشتری مورد نیاز است و تشخیص ایرادهای طراحی در کد دشوار می باشد. تحلیل ریسک باید برای معماری ها انجام شود زیرا در برنامه امنیت نرم افزار نقش بسیار مهمی ایفا میکند .[1] شناسایی ریسک بسیار مفید است و معیارهای امنیت نرم افزار میتواند با کمک آن در نظر گرفته شود. تعیین کمیت ریسک و اثر آن باید در محیط توسعه نرم افزار محاسبه شود زیرا نگرانی های مستقیمی در این تجارت دارد. یکی از سوالاتی که سازمان ها عموما با آن روبرو هستند این است که سیستم من تا چه اندازه امن است.
پاسخ به این سوال اغلب دشوار است. ریشه بیشتر مشکلات امنیتی نرم افزاری است که به گونههای غیر منتظره در مقابل حملات شکست می-خورد. بر خلاف پژوهش های گسترده در مهندسی امنیت، اندازهگیری امنیت هنوز مسأله دشواری است .[2] در حین اینکه ما اندازهگیری امنیت با اطمینان کامل نداریم، اغلب برای ارزیابی امنیت به اندازهگیری ریسک تکیه میکنیم. استفاده از ریسک تجاوزات برای ارزیابی تصمیمات امنیتی یک عمل معمول است که یک مکانیزم سیستماتیک برای بهینهسازی هزینه و منابع فراهم میکند. بخش مشکل آن فراهم کردن اطلاعات دقیق از حملات و احتمال آنها است. به دلیل اینکه سیستم ها معمولا در معرض تغییرات مداوم هستند ریسک های مرتبط به آنها نیز تحت تأثیر این گونه تغییرات قرار میگیرند. با این حال، ارزیابیهای ریسک معمولا به اندازه تغییرات در سیستم تکرار نمیشود. با گذشت زمان، تخمین های اولیه ریسک منسوخ میشود و ممکن است منجر به سیستم هایی با امنیت کمتر شود.
-2 معماری نرم افزار
دانش معماری نرم افزار برای به کار بردن روش تحلیل سلسله مراتبی پیشنهادی ضروری است. هر کدام از اجزا باید شناسایی شوند و تعامل آنها با دیگر اجزا باید برای ساخت مدل DTMC مربوط به سیستم در نظر گرفته شود. معماری سیستمهای نرم افزاری باید در فرم استاندارد در دسترس باشد. اطلاعات مربوط به تعاملات بین اجزا باید با تجربه به دست آمده از اجزای نرم افزاری مشابه تخمین زده شود. یک روش استاندارد برای تخمین احتمالات انتقال کنترل جریان بین اجزا از احتمالات وقوع سناریوهای گوناگون اجرا بر اساس پروفایل عملیاتی سیستم است. قابلیت اطمینان، کارایی و تقاضا و غیره اطلاعات کمی مربوط به مشخصات خود اجزا است. همانطور که توسعه نرم افزار ادامه مییابد، تخمین ها بهتر میشوند و در نتیجه تحلیل با زمان از لحاظ دقت بهبود مییابد.
-3 استراتژی آزمون
معماری ساختاری را فراهم میکند که از طریق آن یک سیستم پیچیده یا بزرگ میتواند فهمیده و استدلال شود. ضعف ها قبل از اینکه ساخت سیستم انجام شود قابل شناسایی است. برای ایجاد چنین ساختاری، معمار سیستم مجموعهای از اجزا و ارتباطات گوناگون بین آنها را به هنگام تجرد دیگر جزئیات سیستم برای نمایش بر میگزیند و بنا بر این یک چشم انداز ویژه به وجود میآورد .[1] معماری یک سیستم نرم افزاری سیستم را از لحاظ اجزا و تعاملات بین آنها تعریف میکند. انتخاب های مختلف اجزا یا ارتباطات، معماری های متفاوت و بنا بر این چشم اندازهای مختلفی از سیستم به وجود میآورد. آزمون باید یک جزء مجتمع از چرخه کامل توسعه نرم افزار باشد. روش دقیق فرایند آزمون وابسته به چرخه عمر توسعه نرم افزار است. چرخه ممکن است افزایشی یا تکراری باشد و بر همین اساس نرم افزار آزمون باید با استفاده از تکنیک های استفاده شده در تولید خود نرم افزار، توسعه داده شود. در تکنیک های طراحی شی گرا موارد بسته بندی و پنهان کردن اطلاعات به تکنیک های آزمون متفاوتی نیاز دارند. آزمون سیستم نرم افزاری شی گرا پیچیدهتر و دشوارتر از چرخه عمر سیستمهای سنتی است. به خاطر وجود تکنیک های پنهان کردن اطلاعات در زبانهای شی گرا بخش هایی از کدهای نرم افزار غیرقابل دسترسی است و این ممکن است مانع بکارگیری بعضی از تکنیک های آزمون شود. میتوان به یک کلاس اختصاصی آزمون امتیازات دسترسی ویژه داد بدون اینکه تمامیت طراحی را سازگار کرد. اگر ما به نیازمندیها اجازه دهیم که در فازهای بعدی غیر از فاز تعریف نیازمندی های نرم-افزار (SRS) تغییر کنند، به این معنی است که نیازهای کاربران یک سیستم ممکن است با گذشت زمان تغییر کرده و نیازمندیهای قرار گرفته
