مهندسي امنيت در web application(قسمت دوم)

 
اهداف
 
فعاليت اهداف امنيت يک فعاليت واضح است که به شما کمک مي کند تا حدود و محدوديتهاي امنيت نرم افزار خود را مشخص نمائيد . بنابراين شما مي توانيد تلاشهاي خود را اولويت بندي نمائيد و بر مبناي trade off ها عمل کنيد . ا
امنيت يک ويژگي کيفيت است که بايستي با ساير ويژگيهاي کيفيت بالانس شود . شما بايستي در ابتدا مشخص کنيد که امنيت براي يک پروژه خاص چقدر مهم است . معرفي کردن اهداف امنيتي به شما کمک مي کند تا بدانيد که چه کاري و در چه زماني از ديد امنيت انجام دهيد .
نقطه ابتدا اين است که شما مشخص کنيد که چه چيزي مي خواهيد رخ ندهد . به عنوان مثال شما نمي خواهيد داده يک مشتري براي مشتري ديگر فاش شود . براي اين فعاليت شما بايستي مشخص کنيد که چه چيزي درون حوزه امنيت اطلاعات شما مي باشد . اين کار به شما کمک مي کند که در مورد confidentially ، integrity و availability (CIA) فکر کنيد .
براي مشخص کردن اهداف امنيتي به سوالات زير پاسخ دهيد
  • چه داده اي از client را بايستي محافظت کنيد ؟ آيا برنامه کاربردي شما کد کاربري و رمز عبور ، اطلاعات جزئي حساب کاربري ، سابقه و transaction مالي دارد يا خير ؟
  • آيا شما يک نيازمندي امنيتي پذيرفته شده نظير سياست گذاري امنيتي ، قوانين محرمانگي ، قواعد و استانداردهاي پذيرفته شده داريد يا خير؟
  • آيا شما نياز داريد که از دارايي هاي معنوي سازمان مانند شهرت ، اطلاعات محرمانه تجاري يا دانش سازماني محافظت کنيد يا خير ؟ دو تکنيک وجود دارد که مي تواند به شما کمک کند تا اهداف امنيت خود را بيان کنيد . يک روش ساده استفاده از ماتريس نقش ها مي باشد که شامل نقشها ، اشيائي که بر روي آنها عمل مي کنند و ميزان دسترسي مي باشد . روش ديگر اين است که نيازمنديهاي عملياتي و سپس نيازمندي هاي CIA مرتبط با هر کدام از آنها مشخص گردد .
  • راهبرد زير کمک مي کند تا اهداف امنيتي خودتان را مشخص نمائيد .
  • از يک سناريو براي تنظيم حدود استفاده کنيد . آيا نيازمنديهاي عملياتي خارج از scope مي باشد ؟
  • اهداف خود را به نيازمنديها و محدوديتها تبديل کنيد .
  • برعکس براي اينکه از اشتباهات عمومي در زمان تعريف اهداف امنيت جلوگيري شود.
  • سعي نکنيد که همه اهداف امنيت خود را در ابتدا شکل دهيد . در ابتدا فقط به مواردي بپردازيد که در طراحي تاثير دارد .
  • هيچ گاه مستندي ايجاد نک��يد که هيچ کس استفاده نمي کند يا حتي به آن نگاه نمي کند . شما بايد مستنداتي را ايجاد کنيد که براي مرحله بعدي به آن نياز داريد . بقيه چيزها مي تواند يک checklist باشد .
  • اگر اهداف مهم هستند آنها را تبديل به آيتم هاي کاري نمائيد.
مدل سازي تهديد
شما نياز داريد که با تهديدات سيستم خود آشنا باشيد . بنابراين شما خواهيد دانست که آيا مکانيزم امنيت موثر مي باشد يا خير . مدل سازي تهديد تکنيکي است که شما مي توانيد براي شکل دادن به طراحي نرم افزار خود استفاده نمائيد و به شما جهت تصميمات آگاهانه در مورد مسائل کليدي امنيت کمک مي کند . در فرم ساده يک مدل تهديد يک representation سازمان يافته از تهديدات ، حملات و آسيب پذيري هاي مرتبط با سيستم شما مي باشد .
در طي طراحي يک مدل سازي موثر به شما کمک مي کند که به سرعت سناريوهاي what if خود را تکميل کنيد . مدت طولاني قبل از اينکه يک اقدام هزينه بر را انجام دهيد شما به سادگي ارزيابي مي کنيد که آيا راه درستي را مي رويد يا خير .
در عمل ما مي بينيم که اکثر فعاليت هاي مدل سازي تهديد ، مدل تهديد زير ساخت را از مدل تهديد برنامه کاربردي جدا مي کنند . در برخي از کمپاني تهديدات شبکه ، سرورها ، desktop ها و برنامه هاي کاربردي از يکديگر جدا مي شود که باعث مي شود ارتباط و مالکيت بهتر بيان گردد . عنصر کليدي اين است که اشتراک مهم بين برنامه کاربردي و زير ساخت را بيان نمائيم . هم اکنون مدل تهديد زير ساخت به عنوان يک ورودي براي مدل تهديد برنامه کاربردي مي باشد .
 راهبرد زير کمک مي کند تا مدل تهديد را بسازيد .
  •  مدل تهديد را به صورت افزايشي ارائه کنيد . در مدل به چيزهايي که مي دانيد ، چيزهايي که نمي دانيد و چيزهايي که نياز است که بعدا بدانيد توجه کنيد .
  •  از شيوه مبتني بر سوال استفاده کنيد . زماني که شما تهديدات ، حملات و آسيب پذيري ها را بيان مي کنيد پرسيدن سوالات بهتر مي تواند شما را به جوابهاي بهتر راهنمايي کند .
  • از مدل تهديد براي معرفي کردن اينکه چه کدي بايد prototype و تست شود استفاده کنيد . مدل تهديد بايستي تصميمات مهندسي داراي ريسک بالا را آشکار سازد که کانديداهاي مهمي براي اولويت بندي جهت prototype و يا تست مي باشد .
  • از تکنيک هاي متعارف استفاده کنيد . شما مي توانيد از تکنيک هاي متعارف مانند آناليز use case ها ، آناليز جريان داده ، شيوه هاي مبتني بر پرسش ، ماتريس نقش ها و طوفان مغزي استفاده نمائيد .
  • از چهارچوب هاي مبتني بر الگو استفاده کنيد . اين الگوها مجرايي از دانش فرد خبره به سمت توسعه دهنده نرم افزار مي باشد که مي تواند فکر وي را شکل دهد .
  • فعاليت مدل سازي تهديد خود را به دوره هاي از پيش تعيين شده تقسيم کنيد .
  • آسيب پذيري ها را بر مبناي مدل تهديد خود شناسايي نمائيد . مهمترين خروجي قابل عمل از مدل سازي تهديد ، ليست آسيب پذيري هاي قابل حمله مي باشد . از اشتباهات عمومي زير اجتناب کنيد : همه کارها را در ابتدا انجام ندهيد .
  • از مدل سازي تهديد به عنوان يک راه حل معجزه آسا استفاده نکنيد . اين يک فعاليت کليدي مي باشد ولي نمي تواند جايگزين مرور امنيت زيرساخت و طراحي يا مرور کد گردد.
  • مدل سازي تهديد خود را آنقدر سنگين و رسمي نکنيد که در طي توسعه نرم افزار قابل استفاده نباشد .
  • چيزي به خارج از تهديدات و حملات در مدل سازي تهديد توضيح ندهيد . براي اطلاعات بيشتر Threat Modeling Web Applications در http://msdn.com/ ThreatModeling را ببينيد . به عنوان مثال مدل تهديد مربوط به تهديد cryptography در web application به صورت زير مي باشد : معرفي تهديدات امنيتي با سوالات زير انجام مي شود :

    چه الگوريتم يا تکنيک رمز نگاري استفاده مي کنيد ؟

    آيا از الگوريتم رمز نگاري شخصي خود استفاده مي کنيد ؟

    چرا از اين الگوريتم خاص استفاده مي کنيد ؟

    طول کليد رمزنگاري چقدر است و چگونه از آن حفاظت مي کنيد ؟

    چند وقت به چند وقت کليدها تغيير مي کند ؟

    چگونه کليدهاي رمز نگاري توزيع مي شود ؟ رمز نگاري را با مشاهده اين تهديدات عمومي مرور کنيد.

    استفاده از يک الگوريتم رمزنگاري شخصي

    استفاده از الگوريتم اشتباه و يا داراي کليد کوتاه

راهبرد طراحي
ايا تيم توسعه نرم افزار شما از قوانين ، نمونه ها و الگوهاي طراحي امنيت نرم افزار اثبات شده استفاده مي کنند ؟ اگر شما از برخي از اينها استفاده نکنيد شانس کمتري براي موفقيت خواهيد داشت . فعاليت راهبردهاي امنيت جايي است که شما پيشنهادات مربوط به طراحي امنيت را جستجو کرده ، جمع آوري مي کنيد و به صورتي مفيد که براي تيم توسعه شما مناسب مي باشد سازماندهي مي کنيد .
يک راهبرد مناسب که بيشتر از فقط يک توصيه مي باشد . اين که از input validation استفاده کنيد يک ايده خوب است ولي يک راهبرد مناسب نمي باشد . اجازه دهيد که اين ايده را به چيزي تبديل کنيم که قابل عمل باشد
  •  کجا آن را انجام دهيم : به validate کردن ورودي کاربر در سمت client اعتماد نکنيد . از آن استفاده کنيد تا تعداد رفت و برگشت ها به سرور را کاهش دهيد ، ولي به امنيت آن اعتماد نکنيد .
  • چرا : کد هاي سمت سرور بايستي validation خود را انجام دهند زيرا حمله کننده ممکن است کد هاي سمت client را دور زده يا آنها را تغيير دهد .
  • چگونه : از شيوه اجازه دادن allow بر روي رد کردن deny استفاده کنيد . بدليل اينکه تقريبا غيرممکن است که شما بتوانيد همه انواع مختلف ورودي هايي بد را مشخص کنيد . به جاي آن مي توانيد چيزي که يک ورودي خوب شبيه آن مي باشد مشخص کنيد و بر اساس آن فيلتر را انجام دهيد . يک راه موثر براي محاسبه موفقيت راهبردها اين است که آيا آنها ما را به نتيجه مي رساند و آيا قابل تکرار مي باشد .
در اينجا چيزهايي را که بايد در زمان ساختن راهبرد طراحي دنبال کنيد آمده است :
  •  از دسته بندي ها براي قالب بندي فضاي مساله و سازماندهي اطلاعات استفاده کنيد .
  • از شيوه چه کاري بايد انجام دهيم ، چرا و چگونه استفاده کنيد . براي هر راهبردي که مي خواهيد تيم توسعه شما دنبال کنند آن را در يک کار قابل انجام با قوانين و مثالهايي به صورت کد در صورت امکان خلاصه نمائيد .
  •  از کلمات ساده استفاده کنيد مانند انجام دهيد ، انجام ندهيد ، بايد ، نبايد و ... . اين به توصيف راهبرد کمک مي کند .
  • توضيح دهيد که چه زماني اين راهبرد مناسب مي باشد و چه زماني مناسب نمي باشد .
  •  از راهبردهايي که هوشمندانه و قابل درک مي باشد استفاده کنيد . اين واضح به نظر مي رسد اما ممکن است در به سادگي در تله مستند کردن چيزهايي بيفتيد که همه آن را مي دانند . بيشتر توجه خود را صرف اطلاعاتي کنيد که غافلگير کننده مي باشد . اشتباهاتي که بايستي از آن اجتناب کنيد.
  •  همه راهبردها را در ابتدا ايجاد نکنيد . بر روي آنهايي تمرکز کنيد که تاثير فوري بر روي نيازمندي ها و هر تکنولوژي اي که در حال ارزيابي آن هستيد و يا از آن استفاده مي کنيد دارد .
  • چرخ را از نو اختراع نکنيد . راهبردهاي امنيت زيادي در حال حاضر وجود دارد . آيتم کليدي اين است که آن را پيدا کرده و به چيزي تبديل کنيد که تيم شما بتوانند بر روي آن عمل کنند .
  •  راهبردهاي خود را در مستنداتي که هرگز از آن استفاده نمي کنيد زنداني نکنيد . شما نياز داريد که بهترين رسانه براي راهبردهاي خود را با جا دادن آنها در فعاليت ها و گردش کار ها تعيين نمائيد .
  • با استفاده از اين قوانين ساده شما مي توانيد راهبردهايي را ايجاد کنيد که قابل عمل کردن باشند . به شما بگويد که چه کاري انجام دهيد ، چرا بايد آن را انجام دهيد و چگونه بر اساس آن عمل کنيد . مرور زيرساخت و طراحي شما ممکن است در حال حاضر يک سري مرور بر روي طراحي انجام دهيد . احتمالا در فعاليت جاري مرور طراحي خود امنيت را پراکنده کرده ايد .
مساله اي که در اين شيوه وجود دارد دو مورد زير مي باشد :
  • شما بيش از حد مرور طراحي موجود خود را پيچيده کرده ايد .
  • شما تاثير و کارايي پيدا کردن جنبه هاي امنيتي را محدود کرده ايد .
اشتباه نکنيد : مرور طراحي کلي مي تواند موثر باشد و آنها قطعا جايگاه خود را دارند اما آنها هيچ گاه نتيجه اي را که يک مرور طراحي با تمرکز بر روي امنيت را نخواهند داشت . زماني که شما يک فعاليت را براي يک دامنه مساله خاص بهينه مي کنيد شما مي توانيد چيزهاي زايد آن را حذف کنيد تا به کارايي بالاتر برسيد .
در مورد دقتي که با حذف کردن هر چيزي که غير مرتبط مي باشد به دست آمده باشد . زماني که شما بر روي امنيت متمرکز مي شويد به صورت تصادفي بر روي ساير ويژگيهاي کيفيت متمرکز نمي شويد مگر اينکه يک اشتراک مستقيم وچود داشته باشد . يک مثال براي زماني که امنيت و performance با هم اشتراک دارند اين است که در صورتي که مي خواهيد از يک راه حل SSL استفاده کنيد نيازمندي امنيت ممکن است به شما بگويد که شما مي توانيد از راه حل نرم افزاري استفاده کنيد يا نياز به استفاده از راه حل سخت افزاري داريد .
چيزي که در مورد مرور زيرساخت و طراحي مهم است اين است که چيزهايي را که مي دانيد ، چيزهايي را که نمي دانيد و چيزهايي را که در آينده بايستي بدانيد را مشخص کنيد . شما بايد يک بالانس برقرار کنيد که آيا راه حل سريعتر اين است که در مورد يک مساله فکر کنيد و يک تئوري داشته باشيد يا اينکه آن را بسازيد و تست و ارزيابي کنيد . بهترين چيز در مورد مرور زيرساخت و طراحي امنيت اين است که شما به صورت موثر حوزه تست هايي را که مي خواهيد انجام دهيد مشخص نمائيد و آنها را اولويت بندي کنيد .
مهمترين مرحله ابتدايي مرور اين است که ابتدا از پايان در ذهن خود شروع کنيد . نيازي نيست که همه جزئيات را در نظر بگيريد بلکه بايستي چيزهايي را که براي تصميماتي که در حال حاضر مي خواهيد بگيريد مهم است در نظر بگيريد . همچنين ممکن است شما دياگرام مربوط به سيستم خود را به شيوه هاي گوناگون تهيه نمائبد . در صورتي که آن بر روي whiteboard نصب گردد مي تواند مفيد باشد . يک چيز جالب در مورد whiteboard اين است که شما را مجبور مي کند که فقط چيزهايي را که مهم است بياوريد چه متوجه اينم مساله باشيد و چه نباشيد . يک راهبرد مناسب زماني که يک ارائه بصري از سيستم را نشان مي دهيد اين است که بر روي لايه منطقي و اشتراک آن با توپولوژي فيزيکي تمرکز کنيد . اگر شما مي توانيد نشان دهيد که چه چيزي استقرار پيدا کرده است و کجا روش صحيحي را انتخاب کرده ايد .
بهترين چيز بعدي که شما مي توانيد نشان دهيد جنبه هاي کليدي مرتبط با امنيت برنامه کاربردي مي باشد ، مانند authentication ، authorization ، validation ورودي و داده و ... .هر کدام از اين جنبه ها بر روي طراحي برنامه کاربردي تاثير گذار مي باشد .
يک راه مناسب جهت اينکه به سرعت مشخص کنيم که بر روي چه جايي براي حداکثر ام��يت تمرکز کنيم اين است که سوالاتي بپرسيم که نتيجه آنها تصميماتي با ريسک بالا مي باشد . به عنوان مثال:
  • چگونه شما درخواست کننده منابع front end ، لايه مياني و لايه back end را تصديق اصالت مي کنيد ؟
  • چگونه سطح دسترسي درخواست دهنده منابع front end ، لايه مياني و back end را مشخص مي کنيد ؟
  • چگونه اصالت را جريان مي دهيد ؟ ايا اصالت درخواست دهنده اوليه را به منابع back end تغيير مي دهيد و يا از يک trusted proxy به جاي درخواست دهنده استفاده مي کنيد) • چگونه ورودي ها را validate مي کنيد . آيا از يک روتين متمرکز براي handle کردن ورودي کاربر استفاده مي کنيد ؟
  • چگونه مطمئن مي شويد که زماني که استثنائي رخ داد اطلاعات حساس را فاش نمي کنيد ؟
  • چگونه عمليات حساس سازماني خود را audit مي کنيد ؟ اين نوع سوالات مشخص مي کند که در آينده چه چيزي را بايد بررسي کنيد . بر اساس اين سوالات شما مي توانيد بفهميد که چقدر در مورد طراحي بايستي نگران باشيد .
در اينجا چگونگي ايجاد يک مرور زيرساخت و طراحي آمده است :
  • براي امنيت مرور خاص آن را انجام دهيد .
  • مديريت زمان را بر روي مرور طراحي امنيت انجام دهيد . شما زمان نامحدودي نداريد . بر اساس اولويت ها زمان بندي و اقدام کنيد .
  • از شيوه مبتني بر سوال استفاده کنيد .
  • مرور امنيت خود را به بسته هاي کوچک تري قسمت بندي کنيد . به عنوان مثال بخش حساس روال و يا مکانيزم مانند validation ورودي و داده را مرور کنيد .
  • مرور طراحي را به عنوان دروازه اي براي ورود به گردش کار روزانه قرار دهيد . اين کار باعث مي شود که خطاها راحت تر در طي مرور و تحليل استاتيک کشف گردد .
  • در اينجا چگونگي اجتناب از برخي از خطاهاي عمومي آمده است.
  • مرور مربوط به زيرساخت و طراحي امنيت را خيلي دير انجام ندهيد . اين کار باعث مي شود که جلوي اشتباهات بزرگ خيلي زود تر گرفته شود .
  • مرور مربوط به طراحي امنيت را با مرور کلي انجام ندهيد و آن را به صورت مجزا انجام دهيد .
  • درگير چيزهاي کوچک نشويد . شما نياز داريد که مشکلات بزرگ که اثر آبشاري دارند را پيدا کنيد.
براي اطلاعات بيشتر Security Architecture and Design Review for Web Applications را در http://msdn.microsoft.com/library/en-us/dnnetsec/html/THCMCh05.asp ببينيد .
مرور کد
چه روشي براي پيدا کردن مشکلات امنيتي از مرور کد بهتر است . مرور امنيت کد اين نيست که بررسي کنيم که آيا کد کار مي کند يا خير . اجرا کد اين را به شما مي گويد . اين کار به شما مي گويد که آيا کد اهداف امنيتي را برآورده مي کند يا خير . مرور کد بر اساس امنيت به شما اجازه مي دهد تا يک آناليز مفهومي بر روي کد انجام دهيد .
اين مهم است که در ذهن خود نگه داريد که برخي از گزينه هاي امنيت درباره ساخت کد يا نمونه اثبات شده مي باشد و ساير گزينه ها در مورد ريسک هاي کسب و کار مي باشد .
خبره هاي امنيت 4 مرحله را براي مرور امنيت کد استفاده مي کنند .
  1. مشخص کردن اهداف امنيت مرور کد
  2. انجام دادن scan اوليه : اين کار شامل انجام يک آناليز استاتيک براي پيدا کردن مجموعه اي از نتايج و بهبود دانش خود در مورد اينکه چه جايي بيشتر احتمال دارد مشکلات را زماني که کد را دقيق تر مرور مي کنيد پيدا کنيد .
  3. مرور بيشتر کد جهت مشکلات امنيتي : اينجا جايي است که کد را به طور کامل بررسي مي کنيد تا آسيب پذيري هاي آن را پيدا کنيد . شما مي توانيد از نتايج مرحله 2 استفاده نمائيد تحليل خود را بر روي قسمت هاي خاصي متمرکز کنيد . در اينجا از روش هايي نظير کنترل و آناليز dataflow مي توان استفاده کرد .
  4. براي مشکلات امنيتي که خاص زيرساخت شما مي باشد کد را مرور کنيد . اين مرحله در صورتي که شما مکانيزم امنيتي خود را پياده سازي کرده ايد بسيار مهم مي باشد (يا هر امکاني را که براي رفع يک مشکل امنيت خود پياده سازي نموده ايد)
با وجود اينکه آناليز استاتيک براي پيدا کردن الگوهايي که بايد به دنبال آن باشيد مفيد مي باشد آناليز مفهومي و دانستن اهداف امنيت کليدي هستند تا بدانيد که چگونه شروع کنيد ، چگونه پيش برويد و چه زماني کار شما انجام شده است .
چيزهايي که بايد در زمان مرور کد به آن توجه کنيد
  • زمان خود را بودجه بندي کنيد . بنابراين شما مي توانيد به درستي بر مبناي اولويت بندي ها عمل کنيد .
  • اهداف را تنظيم کنيد ولي مدت زيادي درگير اين کار نشويد . اهداف به شما با تعيين حدود و محدوديتها کمک مي کنند ولي آنها خودشان نهايي نيستند . هر زمان که نياز است آنها را اصلاح کنيد .
  • از چک ليست هاي شخصي استفاده کنيد الگوي اشتباهات خود را پيدا کنيد و از يک checklist براي از بين بردن آنها استفاده نمائيد .
  • براي اينکه از اشتباهات عمومي جلوگيري شود مرور کد مربوط به امنيت را همزمان با مرور کد عادي انجام ندهيد . براي اطلاعات بيشتر بخش How To: Perform Security Code Review for Managed Code (BaselineActivity) را در http://msdn.microsoft.com/library/en-us/dnpag2/html/paght000027.asp ببينيد.
تست امنیت
صحبت در مورد تست امنيت معمولا بر روي تست نفوذ تمرکز دارد . اين روش مي تواند روش white box باشد که شما عملکرد داخلي را مي دانيد و يا روش black box باشد که شما عملکرد داخلي را نمي دانيد . تست black box عمدتا شامل تست مقادير مرزي ، تزريق ورودي بد رفتار و تست مشکلات شناخته شده مي باشد . شواهد زيادي وجود دارد که تست white box براي پيدا کردن مشکلات امنيتي بسيار مناسب تر مي باشد .
 يکي از شکايت هايي که عموما شنيده مي شود اين است که تست امنيت نا محدود است و نمي توان گفت که چه زماني اين کار انجام شده است . مشکل اين است که ما مي خواهيم به يک امنيتي کيفي به اتدازه کافي خوب برسيم . براي performance شما مي توانيد زمان پاسخ را محاسبه نمائيد . ولي براي امنيت مشکل است که confidentiality ، integrity و availability را محاسبه نمائيد . شاخص اينکه چگونه شروع کنيد ، چگونه جلو برويد و کي کار را به اتمام برسانيد به اهداف امنيت شما برمي گردد . موثرترين و کاراترين تست امنيت چرخيدن اطراف اهداف امنيتي و مدل تهديد مي باشد . اين کار منافع تست اکتشافي را نفي نمي کند . براي اين کار زماني که نرم افزار به قدر کافي از لحاظ امنيتي قوي شد معمولا در صنعت از يک third party جهت تست نفوذ به صورت white box و black box استفاده مي شود .
تست استقرار
استقرار زماني است که برنامه کاربردي شما در بر روي زير ساخت مشتري قرار گرفت . بنابراين مرور استقرار آخرين فرصت براي بررسي امنيت مي باشد . با وجود اينکه اولين عموما اولين بار نيست که استقرار يک برنامه کاربردي را انجام مي دهيد اما در عمل به نظر مي رسد که چنين است . چون در بسياري از مواقع دچار همان مشکلاتي مي شويم که در مرور استقرار قبلي نيز دچار آن شده ايم . يک برنامه کاربردي ممکن است رفتارهاي متفاوتي در طي فرايند توسعه و توليد در سناريوهاي مختلف داشته باشد . گاهي توسعه دهنده محدوديتهاي infrastructure را نمي داند .
گاهي نرم افزار برخي از سياست هاي سازمان را که در طي مسير گم شده است نقض مي کند . گاهي نرم افزار با يک حساب کاربري داراي سطح دسترسي بالاتر تست مي شود و در زمان استقرار به درستي با حساب کاربري که داراي دسترسي پايين تري مي باشد . گاهي برنامه کاربردي بر روي يک سرور باز ساخته و تست مي شود و زماني که بر روي يک سرور به بسته شده استقرار مي يابد اجرا نمي شود .
تست استقرار شما بايستي بسياري از غافلگيري ها را تا حد ممکن از بين ببرد . شما ممکن است دست کم يک محيط اجرا قبل از ارائه محصول نهايي داشته باشيد . در حالت ايده آل شما سيکل هاي ساخت را قبلا در زمان توسعه نرم افزار داريد که بر اساس آن مي توانيد رفتار نرم افزار را در محيط اجرا حدس بزنيد . کدي که بر روي ماشين developer در يک شرايط خاص اجرا مي شود ممکن است در محيط مشتري به شکل ديگري اجرا شود . اين يک چيز عمومي مي باشد نه يک استثناء . کد هايي که به صورت امن در طي توسعه معمولا با Web Server و Database بر روي يک ماشين اجرا مي شوند ممکن است به اين خوبي در محيط مشتري اجرا نشود .
معمولا تعداد زيادي اجزاي قابل انتقال با گزينه هاي پيگربندي وجود دارد که مي تواند بر روي رفتار نرم افزار شما در محيط اجرا تاثير بگذارد .
در صورتي که شما دکمه ها ، کليد ها ، تنظيمات و يا وضعيت هاي متعددي داريد دسته بندي انها مي تواند به شما کمک کند . يک ليست flat از تنظيمات ممکن است شما را دچار اشتباه نمايد .
به عنوان مثال يک دسته بندي براي حساب کاربري ممکن است به صورت زير باشد :
  • حسابهاي کاربري حداقل دسترسي را دارند
  • استفاده از سياست password هاي قوي اجباري مي باشد .
  • جدا کردن سطح دسترسي ها اجباري مي باشد .
با استفاده از اين روش شما مي توانيد به سرعت قواعد مورد قبول ، محدوديت هاي زير ساخت ، توصيه هاي فروشنده و ... را اعمال نمائيد . اين کار همچنين قابليت چک کردن مرور استقرار را تکرارپذيرتر مي کند . اينجا چيزهايي را که در زمان ساختن يک مرور استقرار بايستي به آنها توجه کنيد آمده است :
  • بايستي چک ليست هايي خود را به روز نگه داريد . در طي زمان محيط ، قواعد مورد قبول و زيرساخت تغيير مي کند و check list هاي شما نياز به نگهداري دارد
  • فقط به check list ها نپردازيد و آن را با تفکر و تحليل مفهومي جايگزين نکنيد .
  • براي اطلاعات بيشتر Security Deployment Review Index را در http://msdn.microsoft.com / library/en-us/dnpag2/html/ SecurityDeploymentReviewIndex.asp ببينيد .
چهار چوب هاي امنيت وب
مشکلات با الگوي خاص بارها و بارها براي ما رخ مي دهد .
چهارچوب هاي امنيت وب (http://msdn.microsoft.com/library/en-us/dnpag2/html/TMWAcheatsheet.asp) به شما کمک خواهد کرد که مشکلات تکراري را دسته بندي کنيد
اين کار تاثير فعاليت هاي امنيت را افزايش مي دهد . در اينجا يک دسته بندي از چهارچوب امنيت وب ايجاد آمده است .
  • اعتبارسنجي ورودي و داده
  • Authorization
  • Authentication
  • مديريت پيکربندي
  • رمز نگاري
  • داده هاي حساس
  • مديرت استثنائات
  • مديريت session
  • مميزي و log
اين مجموعه از دسته بندي ها تکرار شده در طي زمان پايدار گرديده است . زيرا اينها دلايل ريشه اي وقوع مشکلات امنيتي هستند . براي اطلاعات بيشتر Cheat Sheet: Web ApplicationSecurity Frame را در http://msdn.microsoft.com/library/en-us/dnpag2/html/ TMWAcheatsheet.asp.) ببينيد .

ارسال نظر

آخرین نظرات

Comment RSS