امنیت و لحاظ آن در چرخه تولید نرم افزار ها

چهارشنبه, 30 خرداد 1386 ساعت 16:14
    نویسنده: مجتبی کمریان این آدرس ایمیل توسط spambots حفاظت می شود. برای دیدن شما نیاز به جاوا اسکریپت دارید
این مورد را ارزیابی کنید
(1 رای)

چکیده

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

مقدمه

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

 مطالعات بی‌شمار و توصیه‌های تحلیل‌گران بیان‌گر اهمیت ارتقای امنیت نرم‌افزار در چرخه حیات تولید نرم‌افزار(Software Development Life Cycle - SDLC)،به جای کشف و رفع آن پس از تولید و توزیع گسترده آن می‌باشد. گمان بر این است  توجیه این قضیه روشن باشد. شرکت‌های تولیدکننده نرم‌افزار برای کشف نقایص امنیتی در نرم‌افزار خود، به صورت مستقیم و غیرمستقیم هزینه می‌کنند. تخصیص منابع لازم برای رفع نقص و تهیه وصله‌های امنیتی و انتشار آن می‌تواند میلیون‌ها دلار هزینه در بر داشته باشد. به علاوه، سوءاستفاده از یک نقص امنیتی در نرم‌افزاری که در سطح جهان گسترده شده است می‌تواند به مجموعه شرکت‌هایی که از نرم‌افزار استفاده می‌کنند، میلیاردها دلار خسارت وارد کند. از سوی دیگر، تولیدکنندگان نرم‌افزار به دلیل وجود چنین نقیصه‌هایی در نرم‌افزارشان، به خاطر از دست دادن اعتبار، مخدوش شدن نام تجاری خود و یا مزایای موجود در محصولات رقیبان، نیز متضرر شوند. تحقیقی که در سال 2005 توسط موسسه کارنگی – ملون (Carnegie-Melon)  انجام شد، نشان داد که چنین شرکت‌هایی با کاهشی معادل 0/63% در ارزش سهام خود در NASDAQ مواجه بوده‌اند.

گرچه تحقیقی با این جزئیات در مورد نرم‌افزارهای ابرسازمانی (Enterprise )که توسط خود سازمان‌ها تولید یا برون‌سپاری (Outsource) شده‌اند در دست نیست، ولی توافق همگانی بر این است که هر چه نقیصه‌های نرم‌افزار در مراحل آغازین تولید آن کشف و رفع شود، هزینه نهایی تولید کمتر خواهد بود. چنان که در نمودار زیر نیز نشان داده شده است:

طبق تحقیق منتشر شده از سوی بی. بوهم و وی. باسیلی (B. Boehm and V. Basili)  در IEEE Computer رفع یک خطای نرم‌افزاری پس از نصب 100 برابر زمانی است که خطا در مراحل اولیه تولید نرم‌افزار کشف و اصلاح شود. در مورد نقایص امنیتی این رقم بالاتر نیز خواهد بود، چرا که علاوه بر هزینه فوق، هزینه جبران خسارت ناشی از سوءاستفاده از این نقایص به منظور دزدی اطلاعات، خراب‌کاری و سایر حملات نیز بر دوش تولیدکننده سنگینی خواهد کرد.

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

تعریف 1: امنیت نرم افزار

امنیت نرم افزار یک نظام جوان است که خصوصیات امنیتی نرم افزار را هنگامی که در حال طراحی، آزمایش، پیاده سازی و بکارگیری است، مورد خطاب قرار می دهد. یعنی در دوره زمانی تولید نرم افزار یا Software Development) Life Cycle (SDLC که شامل فعالیت های امنیتی زیادی در مراحل مختلف درSDLC، مانند مدل کردن تهدید، مدیریت خطر و آزمایش های امنیتی است.

تعریف2 : ویروس

هر عاملی که بتواند امنیت  اطلاعات را در یک نرم افزار یا وب پایگاه به مخاطره بیاندازد از آن به عنوان ویروس یاد می شود.

ویروس ها از نظر حمله به بخشهای مختلف سیستم انواع مختلفی دارند:

  • ● حمله به نرم افزار
  • ● حمله به سخت افزار
  • ● حمله به ویندوز
  • ● حمله به سیستم عامل

موانع لحاظ امنیت در چرخه تولید

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

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

تصوربرداشت نادرست1

برنامه زمانی تولید نرم‌افزار، حتی برای لحاظ امنیت، نمی‌تواند بیشتر از آنچه هست طولانی شود.

واقعیت

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

تصور برداشت نادرست2

با وجود انجام "مرور همتا"( Peer) دیگری نیازی به "مرور امنیتی" نیست.

واقعیت

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

مسئولیت‌های اصلی

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

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

در اینجا چندین پیشنهاد که برای بهبود امنیت نرم افزارها، از اولین مراحل ممکن، می توانیم انجام دهیم، آورده شده است:

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

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

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

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

اینها در دسترس ترین قسمت ها برای سرمایه گذاری هستند تا بتوانیم بیشترین بهبود را حاصل کنیم.

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

  • - تعیین نیازمندی‌های امنیتی: مدیر یا فردی خبره در امر امنیت می‌بایست مصادیق آسیب‌پذیری و نحوه قضاوت در مورد حساسیت آنها را، بر اساس نیازهای کسب‌وکار، معین نماید.
  • - پیکربندی تحلیل: تعاریف داخلی‌ای را که برای شخصی‌سازی (Review) ابزار تحلیل کد برنامه بر اساس سیاست‌های کسب‌وکار مورد نیاز است، تعیین نمایید.
  • - پویش کد برنامه: از ابزار تحلیل کد برنامه برای وارسی برنامه کاربردی مورد نظر و تشخیص نقاط آسیب‌پذیر استفاده کنید.
  • - بررسی نتایج: افراد خبره در حوزه امنیت باید نتایج را، به منظور اولویت‌بندی اقدامات مورد نیاز برای رفع نقیصه امنیتی، بررسی نمایند.
  • - اصلاح نقیصه: با بازنویسی کد، حذف مولفه‌های مشکل‌ساز و افزودن مولفه‌های امنیتی، آسیب‌پذیری‌ها را برطرف کنید.
  • - وارسی اصلاحات: کد را مجددا پویش و اطمینان حاصل کنید که نقیصه‌ها با حفظ کارکرد برنامه، حذف شده‌اند.

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

1- مدل مستقل

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

نحوه کارکرد

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

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

موارد مناسب برای استفاده

سازمان‌هایی با تیم‌های و پروژه‌های کوچک بیشترین بهره را از مدل مستقل می‌برند. در این موارد به‌سادگی می‌توان آموزش‌ها و راهنمایی‌های لازم برای نتیجه‌بخشی تلاش‌های برنامه‌نویسان در جهت تامین امنیت برنامه را فراهم نمود. گرچه ردگیری میزان پیشرفت کار در این مدل دشوار است، ولی از برنامه‌نویسان انتظار می‌رود که از تلاش‌های خود درس بگیرند و آن را در برنامه‌های آتی به کار ببرند. با توجه به سرمایه‌گذاری اندک مورد نیاز در این مدل، به نظر می‌رسد که بهترین روش برای سازمان‌های کوچک باشد. مدل مستقل، برای شرکت‌هایی که به امر یکپارچه ساختن سیستم‌های نوشته شده می‌پردازند و در این کار به تیم کوچکی از برنامه‌نویسان نیاز دارند، نیز می‌تواند کارساز باشد.

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

موارد نامناسب برای استفاده

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

شیوه‌های برتر

- مجموعه‌ای از نیازمندی‌های قابل اندازه‌گیری و قابل اعمال را به برای جهت دادن به عملیات امنیتی تعریف کنید.

- به منظور اطمینان از حذف آسیب‌پذیری‌های کشف شده، بدون لطمه به کارکرد سیستم، "مرور امنیتی کد" را بین تمام برنامه‌نویسان انجام دهید.

- یک برنامه‌نویس آشنا به امنیت را شناسایی کرده یا آموزش دهید، تا به منظور کمک به دیگر برنامه‌نویسان گروه، در تحلیل، بررسی اولیه و انجام مرور امنیتی نقش مربی را ایفا نماید.

2- مدل توزیع‌شده

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

نحوه کارکرد

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

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

موارد مناسب برای استفاده

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

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

موارد نامناسب برای استفاده

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

شیوه‌های برتر

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

3. مدل متمرکز

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

نحوه کارکرد

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

به طور ایده‌آل، تخصیص فعالیت اصلاح آسیب‌پذیری‌ها باید از طریق یک سیستم ردگیری نقیصه‌ها(Defect Tracking System – DTS)و هر یک به برنامه‌نویس خاصی انجام شود. چنین سیستمی برای تیم تحلیل امکان نظارت بر فعالیت رفع عیب تیم تولید را فراهم می‌کند. در این بین، گروه تولید نیز می‌توانند بر ارتقای کد خود تمرکز کند، چه از نظر افزودن ویژگی‌های کارکردی جدید، چه با رفع نقایص امنیتی. در این مدل، تیم نظارت بر امینت نه تنها گروه تولید را در نحوه اصلاح معایب راهنمایی می‌کند، بلکه روش اصلاح را نیز با سیاست امنیتی سازمان هماهنگ می‌سازد. به عنوان مثال، فرض کنید که تیم تحلیل امنیت یک آسیب‌پذیری "تزریق SQL   در روال پردازش شماره کارت اعتباری از یک سیستم پرداخت الکترونیکی کشف می‌کند. روش اصلاح می‌تواند استفاده از یک رویه پایگاه داده، استفاده از SQL دارای پارامتر، یا به‌کارگیری یک روال موجود در سازمان باشد. یک تیم تحلیل امنیت متمرکز می‌تواند روش مناسب را بر اساس سیاست سازمان معین نموده و جهت انجام به تیم تولید ارائه نماید. در این صورت، از تصمیم‌گیری انفرادی و سلیقه‌ای افراد تیم تولید پیش‌گیری خواهد شد.

موارد مناسب برای استفاده

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

با توجه به این که در این مدل از چندین سناریوی محتمل (مانند تولید، نظارت داخلی و مرور خارجی کد) می‌توان استفاده نمود، بنابراین مدل‌های تحویل کد متفاوتی نیز مورد نیاز می‌باشد. اتصال به نرم‌افزار کنترل کد، در صورتی که تیم تحلیل در چرخه تولید نرم‌افزار استقرار یافته باشد، عملکرد خوبی ارائه می‌دهد ولی برای مرور خارجی کد، به دسترسی از راه دور یا ارسال کد بر روی یک رسانه قابل حمل (مانند CD یا USB) مورد نیاز خواهد بود.

موارد نامناسب برای استفاده

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

شیوه‌های برتر

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

آنچه در فوق گذشت آشنایی نسبی با تعریف امنیت در گروه بندی نرم افزارهای رومیزی یا وب را برای ما تداعی می نمود.

امنیت و لحاظ آن در چرخه تولید نرم‌افزارهای اسلامی

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

اگر چه تاکنون امکانات، نیروها و سرمایه های هنگفتی هزینه شده؛ اما هنوز اهداف کوتاه‏مدت و بلندمدت به صورت کلان و خُرد در راستای توسعه تعریف نشده است. در بین سطوح تصمیم‏گیری به ویژه در توسعه عملیاتی حوزه دین، فرهنگ و علم این اتفاق نظر وجود دارد که جهت دسترسی به توان بالای فنّاوری اطلاعات و IT؛ به نتیجه رساندن سرمایه‏گذاری‏های انجام شده؛ ایجاد بستر مناسب جهت جلب اعتماد صاحبان سرمایه، مراجع، مدیران عالی‏رتبه و از طرف دیگر کاربران اعمّ از قشر حوزوی، دانشگاهی و عموم مخاطبان، باید پس از اصلاح دیدگاه نسبت به IT و شناخت تمام توان و امکانات آن، از روش‏های مدیریتی متمرکز و یا راهبری متمرکز بر امکانات، نیروها و سرمایه ها استفاده نمود تا چنین فعالیت‏هایی به صورت منسجم، مطمئن و پایدار صورت بگیرد.

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

روش‏های یکپارچه سازی و نهادینه کردن آن، ما را قادر می‏سازد تا بر ضعف‏ها و ناکارآمد بودن وضعیت فعلی فایق آمده تا بتوایم علاوه بر برنامه ‏ریزی استراتژیک و کلان حوزوی گروه های بزرگ و کوچکِ مربوط به حوزه و حوزویان را امر تسهیل روابط، ارتقاء کیفیت محصولات ارائه شده سوق داده و در نتیجه به احیای رسالت حوزوی و مخاطب‏سازی در عرصه جهانی مخصوصاً محافل علمی دنیا دست یابیم. از این‏رو، ضرورت ایجاب می‏کند جهت نیل به آن توانمندی به بررسی مشکلات توسعه در حوزه، مراکز اسلامی، تبیین وظایف دولت، و نقش آنها در این خصوص و مسائل پیرامون آن بپردازیم و سعی شود تا راهکارهای اساسی آن معرفی گردد.

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

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

بنابراین، لازمه بقاء در میدان رقابت جهانی بین کانون‏ه ای مختلف علمی، فرهنگی و مذهبی برخورداری از چنین فنّاوری با پشتوانه شناخت و اندیشه پاک صورت می‏گیرد و بدون لحاظ آن، امکان حیات اجتماعی مدرن غیر قابل تصوّر است. امروزه یکی از عوامل اصلی بقاء یک نرم افزار در IT و اینترنت قدرت دوام آن در برابر مسائلی همچون امنیت و جامعیت است.

امنیت در نرم افزار ها امتیازی است که می تواند در نهایت امر باعث دوام یا سقوط آن نرم افزار در بازار کار باشد.

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

برای یک سازمان، شناختن فناوری‌های امنیت اطلاعات قابل دسترس، مهم است، تا از آن برای تدوین خط‌مشی‌های امنیتی با توجه به نوع و حساسیت اطلاعات سازمان خود، استفاده نمایند. به علاوه، ارائه این طبقه‌بندی از فناوری‌ها، زمینه‌ساز پژوهش جدیدی از جمله در حوزه دین و مباحث اسلامی خواهد بود.

اطلاعات تکميلي

  • تاریخ انتشار نسخه چاپی: شنبه, 26 خرداد 1386
  • صفحه در فصلنامه: صفحه 34
  • شماره فصلنامه: فصلنامه شماره 18
بازدید 15397 بار
شما اينجا هستيد:خانه پدیدآورندگان فصلنامه شماره 18 (بهار 1386) امنیت و لحاظ آن در چرخه تولید نرم افزار ها