شیرپوینت و ویندوز 8

یکی از قابلیتهایی که برای توسعه دهندگان برنامه های کاربردی بر روی ویندوز 8 عنوان می شود. پشتیبانی همه جانبه از HTML 5 و جاوا اسکریپت است. سوالی که در اینجا مطرح می شود این است که آیا این خبر بدی برای جامعه شیرپوینت است؟
برداشت اولیه این است که ویندوز 8 سودمند خواهد بود. اما چه بلایی بر سر سیلورلایت می آید. آیا ممکن است برای همیشه نابود شود. اگر این اتفاق بیافتد چه بر سر شیرپوینت خواهد آمد؟
به دلایل ذیل می توان گفت ویندوز 8 برای شیرپوینت و جامعه شیرپوینت مفید خواهد بود:
  1. ساخت ویدجت برای ویندوز 8 بر پایه داده های لیستهای شیرپوینت، ایده خوبی برای ارایه اطلاعات مهم به کاربران است. اطلاعاتی نظیر پیش بینی فروش، اعضای جدید، اسنادی که اخیر منتشر شده اند، اخبار داخلی و ...
  2. توسعه دهندگان و برنامه نویسان شیرپوینت ملزم به هماهنگی با گرافیستها و طراحان رابط کاربری می شوند.
  3. احتمالا ویندوز 8 مشکلات رابط کاربری شیرپوینت را توسعه و بهبود می دهد. رابط کاربری مبتنی بر وب فعلی شیرپوینت خوب و ساده است و برای برنامه نویسان امکان برخی توسعه های ساده و برای کاربران امکان دسترسی به اطلاعات را فراهم می کند. اما در دنیای امروز این کافی نیست و کاربران انتظار دارند از یک محیط یکپارچه بر روی دستگاههای مختلف استفاده کنند.
  4. روال برنامه نویسی سمت سرور مشابه قبل خواهد بود. HTML 5 و جاوا اسکریپت یک نگرش جدید برای استفاده از داده ها و نمایش آنها می باشند. و ساختار سمت سرور کماکان مانند قبل خواهد بود
 

ساز و کار تعامل نظام پيشنهادها و مدیریت دانش(قسمت دوم)


تاریخچه مدیریت دانش
انسان تا کنون دو دوره اقتصادی را پشت سر گذاشته است . زمانی اقتصاد بشری مبتنی بر کشاورزی بود . پس از آن با ابزارگرایی و آشنایی با اعجازی که علوم مکانیک و سپس برق ایجاد نمود ، ددوره اقتصاد صنعتی پایه گذاری شد . در این دوره ها زمین و کار به عنوان اصلی ترین عناصر و سرمایه های آدمی تلقی می شدند . " توانگر" نیز به کسی اطلاق می گردید که بیشترین بهره مندی را از این دو نوع دارایی داشت . اما عصری که در آن زندگی می کنیم ، بدون تردید در هیچ کدام از دو عصر کشاورزی و صنعتی نمی گنجد. اگر چه کماکان زمین و کار دو مزیت مناسب در برتری جویی ها محسوب می شوند ، اما در عصر کنونی ، که ب�� عصر " اطلاعات و دانش " موسوم شده است ، مزیت اصلی در " سرمایه دانشی" نهفته است . هم اکنون برگترین شرکتهای دنیا ، برتری اصلی خود را نه در دارایی های انباشته ناشی از کارخانجات و حتی بازار بزرگ ، بلکه در " دانش در جریان فرآیندهای خود " کسب نموده اند .
نمودار شماره 2 نشانگر حضور " نیروی کار "، " سرمایه " ، " زمین " و " دانش " در سه اقتصاد مذکور می باشد . همچنان که ملاحظه می شود ، اقتصاد امروز آنچنان بر پایه دانش شکل گرفته که از آن به عنوان " اقتصاد دانش محور " یاد می شود .
در مقاله پیش رو سعی بر تبیین مفاهیم کاربردی سیستم های نظام پیشنهادها و مدیریت دانش و همچنن تشریح چگونگی برقراری ارتباط میان آن دو در راستای اهداف یک سازمان می باشد .
تمامی این مسائل و وضوح تغییرات ایجاد شده در روند اقتصاد جهانی و توجه صنایع و شرکت های پیشرو به حفظ موقعییت خود در بازار جهانی ، باعث خلق مفهوم و دانش جدید تحت عنوان مدیریت دانش گردیده است . مدیریت دانش ، علم باقی ماندن و پیشرفت کردن در عصر جدید است و مسلح نشدن به آن به مثابه عدم استفاده از ماشین آلات کشاورزی و استفاده از گاوآهن در قرن بیستم می باشد . جهت شفاف تر شدن در دنباله مطلب چگونگی مطرح شدن بحث های مرتبط با مدیریت دانش ارائه می گردد .
کارل اریک سیوبی ( Karl Siveby ) حسابداری سوئدی ، در دهه 90 میلادی زمانی که مشغول ارزیابی ترازنامه مالی چند شرکت بزرگ سوئدی بود . متوجه نکته جالبی شد . بسیاری از این شرکت ها پس از انجام عملیات طولانی حسابداری ، ارزشی در حدود چند کرون سوئد و حتی یک کرون نشان می دادند . حال آنکه قیمت واقعی این شرکت ها که سهامداران حاضر به فروش آن بودند ،بسیار بیشتر از قیمتهایی بود که سرمایه حسابداری نشان می داد .
سیوبی پس از بررسی های مختلف متوجه گردید که بخش اعظم از این اختلاف ( اختلاف بین ارزش شرکتتها در بازازر سهام وقیمت داراییهای مشعهود این سازمانها ) به " سرمایه های دانشی " درون سازمان بر می گردد و برخاسته از توان دانشی این سازمان در حل مسائل تخصصی شان است . اما نکته جالب وارد نشدن این دارایی ها در ترازنامه های حسابداری بود ، چراکه اساساً چیزی تحت عنوان مفهوم " سرمایه های نا ملموس " وجود نداشت .
از سال ها پیش ( تقریباً از جنگ جهانی دوم ) محدود بودن " سرمایه های نا ملموس " و فیزیکی و نیاز به افزایش برنامه ریزی شده آنها ، منجر به خلق شاخه های علمی مختلف شده بود . به عنوان مثال ، برنامه ریزی خطی و پژوهش عملیاتی ، مکان یابی و تخصیص ، طراحی کارخانه ، تعمیرات و نگهداری ، بهره وری ماشین آلات ، برنامه ریزی تولید و . . . همگی در جهت مدیریت سرمایه های ملموس ایجاد شده بود . اما سرمایه های نا ملموس تا آن زمان مورد توجه قرار نگرفته بود .
فعالیت سیبویی و پس از آن بک من ( Beck Man ) ، نوناکا ( Nonaka ) ، ویگ ( Wig ) و . . . باعث گردید ، توجه صنعت گران و عالمان علوم صنعتی به سرمایه ایی بس عظیم ، یعنی سرمایه ای که با وجود تولید اکثریت ارزش افزوده کالا ، کمتر مورد مدیریت و ساماندهی و برنامه ریزی افزایشی قرار می گرفت ، جلب شود .
این مساله وقتی روشن می شود که بدانیم در جهان امروز ، در برخی از دانشهای پایه ، در هر 5 سال و نیم دانش جدید دو برابر دانش موجود ظهور پیدا می کند و در هر روز 3 فرمول شیمیایی و . . . ایجاد می شود .
مفوم مدیریت دانش ( Knowledge Management )
است قبل از آنکه به توضیح مدیریتدانش بپردازیم این سوال به وضوح پاسخ داده شود که اصلاً دانش چیست که مدیریت دانش چه باشد .
لذا به منظور درک بهتر مفهوم دانش و مدیریت دانش ضروری است در ابتدا به بررسی مفاهیم داده ( DATA ) ، اطلاعات ( INFORMATION ) و دانش ( KNOWLEDGE ) و تفاوت و ارتباط میان آنها بپردازیم . عبارات اطلاعات و داده ، گاهی به جای عبارت دانش استفاده می شوند . اما آنها در واقع مفاهیم متفاوتی دارند . درک تفاوت آنها برای انجام یک کار دانش محور بسیار مهم و حیاتی است . لذا به ارائه تعاریف هریک از آنها می پردازیم .
داده :
داده یک واقعیت از یک موقعیت و یا یک مورد از یک زمینه خاص بدون ارتباط با دیگر چیزهاست . در حقیقت ، داده ها حقایق و واقعیت های خام هستند . داده ها منعکس کننده تعاملات و مبادلات کامل و واحد و منسجمی هستند که تحت عنوان جزء نا چیز از آنها یاد می شود . این اجزاء در پایگاههای داده ، ذخیره و مدیریت می شوند .
داده ها حداقل متن را دارند و به تنهایی مفهوم موضوع بزرگتری را القا نمی کنند، تا زمانی که مورد پردازش واقع شوند . JAN و100110 و 12 نمونه هایی از داده هستند . بدون ارائه توضیحات بیشتر ، هیچ برداشتی از این سه داده صورت نمی پذیرد . هریک از این داده ها ممکن است بیانگر زمان ، مقدار ، وزن ، مبلغ ، اندازه ، ماهی از سال و . . . باشند .
اطلاعات :
اضافه کردن زمینه و تفسیر به داده ها و ارتباط آنها به یکدیگر ، موجب شکل گیری اطلاعات می شود . به بیان دیگر اطلاعات داده های ترکیبی و مرتبط همراه با زمینه و تفسیر آن است . اطلاعات در حقیقت داده های خلاصه شده را در بر می گیرد که گروه بندی ، ذخیره ، پالایش ، سازماندهی و تحلیل شده اند تا بتوانند زمینه را روشن سازند . می توان با بررسی اطلاعات به اتخاذ تصمیمات پرداخت . اطلاعات معمولاً شکل اعداد و ارقام ف کلمات و گزاره های انباشته شده را به خود می گیرند و اعداد و گزاره ها را بصورت خلاصه ارائه می کنند .
دانش :
اضافه کردن درک و حافظه به اطلاعات موجب توسعه طبیعی پس از اطلاعات می گردد . خلاصه سازی هر چه بیشتر اطلاعات اولیه به دانش منجر می شود . دانش را در این حالت می توان بینش های حاصل از اطلاعات و داده هایی تعریف کرد که می تواند به روشهای مختلف و در شرایط گوناگون موثر و قابل تقسیم باشد . دانش به حداقل رساندن جمع آوری و خواندن اطلاعات است نه افزایش دسترسی به اطلاعات . دانش کارآمد کمک می کند تا اطلاعات و داده های نا خواسته حذف شوند .

دانش یک ادراک و فهم است که از طریق تجربه ، استدلال ، درک مستقیم و یادگیری حاصل می شود . زمانی که افراد دانش خود را به اشتراک می گذارند ، دانش هریک افزایش می یابد و از ترکیب دانش یک فرد با افراد دیگر ، دانش جدید حاصل می شود . ( شکل 1 )
برخی دانش را صرفاً اطلاعات دانش می دانند . در نظر این افراد ، دانش ، ارزیابی واقعی است . مثلاً اینکه سرمایه سرکت های رقیب ما چقدر است ؟ یا استراژی هایی اتخاذ شده توسط آنها را جزو دانش به شمار می آورند . برخی دیگر ، دانش را تنها محدود به مهارتها و تخصص های کاربردی می دانند . در نظر اینها ، مهارت تراشکار و یا مهارت تدریس یک استاد دانشگاه ، مصادیق واقعی دانش هستند .
اما واقع امر این است که همه این موارد ، مصادیقی از دانش هستند . به طور خلاصه ، هرگونه اطلاعات پردازش شده که در جهت تحقق اهداف ما مفید باشد . دانش به حساب می آید .
از منظر دیگر ، برخی متخصصین دانش را به 4 دسته تقسیم می کنند :
  1. دانش چه چیزی ( Know What )
  2. دانش چرایی ( Know Why )
  3. دانش چگونگی ( Know How )
  4. دانش چه کسی ( Know who )
مثلاً در خصوصی موضوعی مانند " زلزله " :
  • دانش چه چیزی شامل این می شود که بدانیم زلزله در چه محل هایی و با چه قدرتی رخ داده است
  • دانش چرایی علت فیزیکی این رخداد را ارائه می کند . مثلاً می گوید زلزله رخ داده است زیرا لایه های سطحی پوسته زمین با یکدیگر تماس پیدا کرده اند .
  • دانش چگونگی مثلاً برای جلوگیری از زلزله یا کاهش تلفات ناشی از زلزله چه باید کرد یا به تعبیر دیگر چگونه می توان تلفات ناشی از زلزله را کاهش داد .
  • دانش چه کسی به این سوال پاسخ می دهد که چه متخصصینی مهارت پیش بینی زلزله را دارند یا اینکه چه کسانی می توانند در کاهش تلفات زلزله به ما کمک کنند .
از منظر دیگر ، دانش به دو دسته
تقسیم می شوند :
  1. دانش آشکار ( Explicit Knowledge ) : دانشی است که در قالب نوشته ها ، فیلم ، صوت ، عکس ، تصویر و حتی کلام قابل انتقال است . گاهی از آن به عنوان دانش کد شده ( Codified Knowledge ) هم یاد می شود .
  2. دانش ضمنی ( Tacit Knowledge ) : انواعی از دانش نظیر مهارت ، بصیرت ، تجربه ، بینش و شهود است که به راحتی قابل کد کردن نیسشتند . انتقال این دانش بیشتر با انتقال افرادی که این نوع از دانش را دارند از جایی به جای دیگر ، صورت می پذیرد .
خرد ( Wisdom ) :
آخرین مرحله ، حرکت از دانش به خرد و کمال است . خرد همان کاربرد دانش است . به عنوان مثال اگر شخصی اثر غذای پر چرب را در چاقی بداند اما بدون توجه به آن در خوردن غذای پر چرب پرهیز نداشته باشد ، فرد خردمندی نیست . زیرا از دانشی آگاهی داشته که آن را به کار نگرفته است .
هرم دانش :
با توجه به تعاریف و مفاهیم فوق می توان هرم دانش را ترسیم کرد . داده ها در پایین ترین سطح و خرد در راس هرم قرار دارند . برخی اختلاف نظرها درباره جزییات وجود دارد ولی در کل ، وفاق عمومی در باره حرکت و ترکیب کلی هرم دانش وجود دارد . ( شکل 2 )

 

اجراي موفق پروژه هاي شيرپوينتي : رويا يا واقعيت؟


ميزان موفقيت هر پروژه شيرپوينتي به عوامل مختلفي بستگي دارد. مهم ترين فاكتورهايي كه سازمان ها جهت سنجش موفقيت نهايي يك پروژه مدنظر قرار ميدهند چگونگي اجراي آن با توجه به زمان، هزينه و كيفيت كار است. البته بايد توجه داشت كه درك موفقيت هاي ناشي از به كار گيري شيرپوينت توسط موسسات اقتصادي نياز به زمان دارد.
با اين مقدمه و همچنين استفاده قابل توجه از شيرپوينت در بسياري از سازمان ها، با به بازار آمدن MOSS2007 مشكلاتي به وجود آمد. شيرپوينت به عنوان بستر تعاملي مايكروسافت، در چرخه حيات پروژه يك يا چند مورد از معيارهاي موفقيت را تحت تاثير قرار ميدهد.
نويسنده مقاله (با داشتن بيش از 7 سال سابقه و برنده شدن در بسياري از مناقصات و همچنين مديريت توسعه شيرپوينت در موسسات اقتصادي كوچك و بزرگ و در بخش هاي گوناگون صنعت و در بعضي موارد كمك به سازمان ها در به پايان رساندن پروژه هاي ناتمام) دراين مقاله به بررسي دلايل عدم موفقيت پروژه هاي شيرپوينت و آموزش علاقه مندان از طريق اشتراك دانش و تجربه خواهد پرداخت. همچنين به منظور افزايش آگاهي بر بعضي موارد تاكيد بيشتري خواهد گرديد تا در پروژه هاي شير پوينتي با برنامه ريزي درست به موفقيت بيشتري دست پيداكرد.
چرا به نتيجه رساندن پروژه هاي شيرپوينتي مشكل است؟
  • تعريف ضعيف از دامنه كاربرد
  • نبود فرهنگ مناسب پروژه در موسسات اقتصادي
  • مديريت ضعيف گروه هاي ذي نفع
  • نظارت ضعيف بر پروژه
  • مهارت كم در مديريت پروژه
  • برنامه ريزي ضعيف
  • عدم مديريت و تشخيص مناسب احتمال زيان و تغيير
علاوه بر موارد فوق، دلايل ديگري نيز وجود دارند كه سازمان ها بايد از وجود آنها آگاه شوند.
جزئيات دلايل عدم موفقيت در پروژه هاي شيرپوينتي
 در اين جا به بررسي بعضي ديگر از دلايل مهم شكست پروژه هاي شيرپوينت مي پردازيم كه سازمان بايد از آنها آگاهي داشته و با توجه به آنها برنامه ريزي نمايند تا موفقيت در گسترش استفاده از شيرپوينت افزايش يابد:
دست كم گرفتن دامنه كاربرد پروژه
معمولا سازمان هاي متوسط و بزرگ موفق به برنامه ريزي و تخصيص مناسب بودجه براي پروژه ها نميشوند كه اين امر در ارتباط با شيرپوينت نيز صادق است. اين مسائل بيشتر در موارد زير نمود پيدا ميكند:
  •  فعاليت هاي فشرده اقتصادي استراتژيك و عملكردي
  • نظارت بر شيرپوينت
  • توانائي هاو منابع تيم پروژه
  • برنامه ريزي و طراحي
  •  زيرساخت (به منظور حمايت از كار گروهي خارجي و داخلي)
  • نوشتن برنامه ،تست و تحويل (بويژه جهت توسعه با امكانات سفارشي)
  •  انتقال اسناد و محتوا از فايل هاي به اشتراك گذاشته شده و اينترانت هاي موجود و ساير برنامه هاي بنگاه هاي اقتصادي (مانند پايگاه داده ها و غيره)
  • مديريت تغيير وانتشار
  •  فعال سازي و افزايش سازگاري كاربر
  •  بخش پشتيباني IT وپشتيباني كاربر
موفقيت هاي سريع" موسسات اقتصادي جهت اثبات ارزش شيرپوينت
اكثر اوقات، در ابتدا شيرپوينت به عنوان جايگزيني براي اينترانت معرفي مي شود كه به خوبي نيز از عهده آن بر ميآيد. اما بيشتر موسسات اقتصادي در برنامه ريزي هايشان توسسعه وي‍‍ژگي هاي مناسب براي اينترانت را به عنوان نقطه شروع كار مد نظر قرارنمي دهند.
چنين " موفقيت هاي سريعي" در عمل به نسبت كمترند اما در عين حال در جهت بالا بردن انگيزه و افزايش پشتيباني موسسات اقتصادي بزرگتر بسيار ارزشمند هستند و البته استفاده از شيرپوينت در اين موسسات اقتصادي چيزي بيشتر از يك راهكار جايگزين براي اينترانت خواهد بود. پس شايسته است موسسات اقتصادي به كارگيري و توسعه شيرپوينت را جزئي از اهداف استراتژيك سازمان و به عنوان عامل كليدي در بهبود فرآيندهاي كسب و كار مد نظر قرار دهند.
 چنين "موفقيت هاي سريعي" بايد سريع شناسايي شده و به عنوان يك برنامه خروجي همزمان با اجراي پروژه اوليه برنامه ريزي شوند كه نشان دهند كه استفاده از شيرپويت نه تنها در ابتداي كار باعث موفقيت ميشود بلكه ادامه اسنفاده از آن در موسسات اقتصادي باعث بهبود در عملكرد نيزميگردد.
البته برنامه ريزي و مديريت بلند مدت پروژه هاي شيرپوينت را نبايد ناديده گرفت.
در ابتداي كار بيشتر موسسات اقتصادي ، به برنامه ريزي بلند مدت و بويژه معماري اصلي جهت پشتيباني از تغييرات بالقوه در آينده توجه نميكنند. لذا اين نياز بالقوه به سرمايه گذاري مجدد در زيرساخت بعدا هزينه برخواهد شد مانند زماني كه شما ميخواهيد يك اكسترانت راه اندازي كنيد و يا با محتواي واحدهاي تجاري ديگر يكپارچه شويد.
مهم است كه تغييراتي را كه در آينده در زيرساخت و معماري اصلي شيرپوينت انجام خواهد شد را هم اكنون مدنظر قرار دهيد. اين كار از هدر رفتن سرمايه ها و زحمات جلوگيري مي كند.
نبود تجربه شيرپوينتي در تيم پروژه
آيا از نيروهايي استفاده ميكنيد كه تاكنون با شيرپوينت كار نكرده اند؟ آيا از برنامه نويسان شيرپوينت يا مشاورين شيرپوينت و يا هر دو استفاده ميكنيد؟ و يا از معمار شيرپوينت، تحليل گر اقتصادي، طراح وب يا مديرپروژه با تجربه در شيرپوينت كمك ميگيريد؟
در بسياري پروژه هاي بزرگ، تمام اين منابع نياز هستند و در هم آميختن اين نقش ها و تجارب نيروها يكي از دلايل اصلي شكست پروژه هاست، زيرا برنامه ريزي پروژه در تخصيص منابع به خوبي مديريت نشده است و در ابتدا، تيم آن را دست كم گرفته است.
ويژگي هاي شيرپوينت بسيار زياد است و اغلب اعضاي تيم تجربه كافي در ارتباط با امكانات و ويژگي هاي اصلي محصول را ندارند، اين امكانات و ويژگي ها زيرساخت اصلي جهت پشتيباني از اجراي پروژه هاي بزرگ مي باشد. بنابراين شناخت موانع و مشكلات ضروري بوده و باعث ميشود كه منابع و امكانات صحيح را بدست آوريد و بفهميد كه آيا استفاده از يك نيروي مشاور/ برنامه نويس مي تواند نيازها را برآورده سازد. عدم كنترل صحيح منابع باعث ميشود تلاش هاي صورت گرفته براي رساندن پروژه به ضرب العجل ها باعث پيچيدگي بيشتر پروژه گردد به گونه اي كه تلاش هاي نهايي جهت تكميل سيستم عملا باعث صرف هزينه بيشتر و بدتر شدن اوضاع ميگردد و به خاطر يك تجربه اوليه ضعيف يك پايگاه استراتژيك ارزشمند به حال خود رها ميشود.
نبود تجربه تحويل در مديريت پروژه شيرپوينت
مديريت پروژه هاي شيرپوينت و داشتن تجربه زياد و مرتبط بسيار ارزشمند است. اغلب بخش IT و مشاوره بيروني باعث ميشوند كه اينگونه به نظر برسد كه شيرپوينت هم مشابه زيرساخت هاي ديگرمايكروسافت اما اينچنين نيست! و البته مشابه هيچ نرم افزار ديگري در پروژه هاي مرتبط نيز نيست. مديريت پروژه شيرپوينت چيزي بينابين است كه باعث ايجاد چالش بين مديريت IT و مديران پروژه در بررسي موضوعات و مشكلات ميباشد.
زيرساخت اشتباه ومعماري ضعيف
بخشي است كه اغلب ناديده گرفته ميشود اما پرداختن به آن باعث پس انداز سرمايه و هدايت تلاش ها در مسير صحيح مي شود. از آنجايي كه استفاده از شيرپوينت در بخش هاي اينترانت، اكسترانت و وب سايت هاي عمومي گسترش يافته است بنابراين زيرساخت هاي مناسب جهت پشتيباني از كاربران شيرپوينت براي موفقيت عمليات و تحويل ضروري است.
آخرين طراحي معماري تكنيكي شيرپوينت نياز به دسترسي به ساير تكنولوژي ها نظير شبكه ها، سيستم هاي ايمني، سرورهاي پروكسي، سرورهاي ISA، نرم افراز ويروس يابي و پايگاه داده ، دارد. همچنين برنامه ريزي ظرفيت سخت افزاري نيز مهم است زيرا شما بايد براي هر 1مگابايت فضاي اختصاص داده شده به كاربر، بيش از 3 مگابايت فضاي ذخيره سازي براي كل فارم اختصاص دهيد. 
ساخت نرم افزار سفارشي يا پيكربندي ؟
ساخت نرم افزار سفارشي را چنين معنا ميكنند: فعاليتي كه به موجب آن يك برنامه نويس شيرپوينت كار در محيط شيرپوينت كد سفارشي مينويسد. در حالي كه پيكربندي به كارگيري امكانات و تنظيم ويژگي هاي موجود جهت پاسخگويي به نيازهاست.
از آنجايي كه معمولا بسياري ازسازمان ها در مورد پيكربندي اطلاعات كافي ندارند نرم افزار سفارشي را انتخاب ميكنند و اين چنين نيز به نظر ميرسد كه انتخاب ديگري ندارند. اما بايد قبل ازانجام چنين كاري تمام جوانب امر را سنجيد.
MOSS/WSS تكنولوژي هاي فراگيري هستند و توانايي آنها درپشتيباني از محيط از زمان اجراي پروژه تا زمان اتمام و انتقال آن يك قابليت مهم است. مجموعه ويژگي هاي MOSS/WSS بسيارزياد است بنابراين درك قابليت هاي آن اگر براي يك فرد غيرممكن نباشد، حداقل مشكل است. اما اين دليلي براي سفارشي كردن نرم افزار ها نيست بلكه بايد تلاش بيشتري كرد و اگر نياز است قبل از شروع به كار و تخصيص منابع، مهارت ها و تجربيات لازم را ازكساني كه با امكانات شيرپوينت آشنا هستند كسب نمود.
از اين رو قدرت تشخيص اينكه چه زماني يك نرم افزار را سفارشي كنيم داراي اهميت است زيرا براي تغيير سفارشات و ويژگي هاي مورد نظر بارها هزينه ميشود و اين هزينه ها بسيار فراتر از هزينه چند روز كار برنامه نويسان است. براي مثال براي موارد زير هزينه ميشود:
  1. كد سفارشي اوليه
  2. تست اينكه چه موقع مجموعه سرويس ها يا HOT FIX باعث از كارافتادن كدهاي سفارشي ميشود(ممكن است بارها در طول حيات يك بستر اتفاق بيفتد.)
  3. زماني كه به نسخه بعدي شيرپوينت و يا هر محصول جديد ديگري مهاجرت مي كنيد ابزارهاي انتقال از محصول سفارشي شما پشتيباني نميكنند و نميتوانند آنها را منتقل كنند.
خب با اين توضيحات شيرپوينت را سفارشي ميكنيد يا پيكربندي؟ آيا در راستاي پاسخگويي به نيازهاي تجاري سفارشي كردن واقعا نياز است؟ معمولا آسانتر و ارزانتر اين است كه به جاي سفارشي كردن شيرپوينت فرآيند فعاليت اقتصادي را متناسب با استانداردهاي شيرپوينت تغيير دهيد. من خيلي وقت ها شاهد بوده ام كه يك "عمل "سفارشي با هزينه بالا ايجاد ميشود فقط به اين دليل كه شايد يك روزي كاربر از آن استفاده كند كه البته در خارج از آن محيط نيز قابل استفاده نيست.
برنامه ريزي ضعيف براي سازگاري كاربر
نكته مهمي كه در طراحي وگسترش شيرپوينت بايد به آن توجه شود اين است كه اگر در زمان اجراي راه حل هاي شيرپوينت كاربران كمي بتوانند به آن دسترسي پيدا كنند و نتوانند اطلاعات مورد نياز خود را پيدا كنند يا به خوبي از آْن استفاده كنند و يا كاربراني نتوانند به آن دسترسي پيدا كنند ديگر هيچ تلاشي براي استفاده از آن نخواهند كرد و از مزاياي كار گروهي نيز بهره مند نخواهد شد.
برنامه ريزي جهت "اجرا و سازگاري با نيازهاي كاربر" و نتايج حاصل ازآن كليد موفقيت قابل ملاحظه پروژه و چيزي بيشتر از موفقيت در قالب استانداردهاي مربوط به هزينه/كيفيت/ زمان ميباشد.
نتيجه
دراين مقاله به بررسي موضوعاتي پرداخته شد كه سازمان هاي در حال گسترش و آنهايي كه در آينده گسترش خواهند يافت با آن مواجه خواهند شد و در حقيقت بسياري سازمان ها بدليل نبود تجربه و مديريت مناسب انتظارات پشتيبانان اقتصادي و همچنين تصميم گيري ضعيف با بعضي از مشكلات بالا و يا تمام آنها روبروخواهند شد.
بنابراين آنچه سازمان ها بايد جهت پيشگيري از بسياري از اين مشكلات انجام دهند در اين مقاله ذكر گرديد. ساده است، اگر ميتوانيد در حجم كوچك شروع كنيد و با ويژگي ها و قابليت هاي بستر شيرپوينت آشنا شويد.
اگر شما در حال برنامه ريزي براي يك برنامه بزرگ هستيد تمام جوانب امر را به دقت بررسي كنيد، شيوه عمل خود را با دقت بازبيني كنيد و تجربه و دانش را از كساني كه قبلا چنين كاري انجام داده اند كسب كنيد، كساني كه مشكلات وخطرات را ميشناسند و قبل از اين كه شما از منابع و امكانات استفاده كنيد تمام اين راه ها را رفته اند.
سرانجام كمك گرفتن از متخصصين را حتما مدنظر قرار دهيد، از ابتدا از كساني كه چنين تجربه اي دارند و ميتوانند درزمان تغيير به سازمان شما كمك كنند و به كاربران شما امكان استفاده از تمام مزاياي بستر تعاملي شيرپوينت ماكروسافت را ميدهد ضمن اينكه ميتوانيد كاري را كه شما به خوبي از عهده آن بر مي آييد را ادامه دهيد.
اگر شما به منابع بيروني مراجعه كنيد سطوح مناسب انتقال دانش به نيروهاي شما در تمام طول پروژه تضمين ميشود و نه تنها در زمان تحويل.
 

دسترسی کاربر Anonymous به یک Survey در شیرپوینت

اگر بخواهید یک نظر سنجی یا در حالت کلی یک مطالعه (Survey) در سایت ایجاد کنید و از کاربران تعریف نشده (Anonymous) بخواهید در آن شرکت کنند باید تغییراتی در مورد حقوق و دسترسی آن ایجاد کنید. بار اول که به قسمت حقوق دسترسی برای این مطالعه می رویم و مطابق شکل زیر عمل می کنیم.

با گزینه های Read Only رو برو می شویم و نمی توانیم دسترسی به کاربر تعریف نشده بدهیم

برای حل این مشکل به قسمت تنظیمات پیشرفته مطالعه رفته , دسترسی خواندن را به همه پاسخ ها تغییر می دهیم


حال به بخش دسترسی به کاربر تعریف نشده می رویم و مشاهده می کنیم که می توانیم بخش دسترسی را ویرایش کنیم (برای شرکت در نظر سنجی برای کاربران تعریف نشده تیک افزودن موارد - افزودن موارد به لیست‌ها، افزودن اسناد به کتابخانه‌ی سند و افزودن نظرات مباحث وب و مشاهده موارد - مشاهده موارد در لیست‌ها،‌ اسناد در کتابخانه‌های اسناد و مشاهده نظرات مباحث وب و تنظیم هشدارهای ایمیلی برای لیست‌ها را می زنیم)

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

ساز و کار تعامل نظام پيشنهادها و مدیریت دانش(قسمت اول)


چکیده
نظام پیشنهادها یکی از زیرسیستم های نظام مدیریت مشارکتی است که با کمک آن می توان از دانش و اندیشه کارکنان برای مساله یابی و حل مسائل و مشکلات سازمانی بهره جست . در این نظام کلیه کارکنان از عالی ترین رده سازمانی تا پائین ترین سطح آن می توانند تفکر و دانش خود را در قالب پیشنهاد ها، ایده ها ، ابتکارات و نظرات، جهت رفع نارسایی های موجود در روند کاری و بهبود روش های انجام کار و افزایش کیفیت تولید و . . . ارائه دهند . بنابراین نظام پیشنهادها که از آنبه طرح بسیج اندیشه ها یا کازین فردی نیز یاد می شود ، می تواند به عنوان بستری مناسب جهت بکارگیری دانش کاربردی افراد در چهار حوزه دانش چه چیزی ( Know What ) ، دانش چرایی ( Know why ) ، دانش چگونگی ( Know How ) ، دانش چه کسی ( Know who ) در راستایاهداف سازمان و حل مشکلات و بهبود فرآیندها و روابط کاری در یک شرکت ایفای نقش نماید .
در مقاله پیش رو سعی بر تبیین مفاهیم کاربردی سیستم های نظام پیشنهادها و مدیریت دانش و همچنن تشریح چگونگی برقراری ارتباط میان آن دو در راستای اهداف یک سازمان می باشد .
این مقاله در نگاهی اجمالی پتانسیل های موجود در نظام پیشنهادها جهت بررسی هر چه بهتر و آسانتر و بکارگیری هرچه روان تر دانش مجموعه کارکنان یک شرکت برای تعریف و حل مسائل سازمانی، در قالب ساختاری سازمان یافته و هدفمند توام با در نظر گرفتن مسائل انگیزشی می پردازد . بررسی این پتانسیل ها ، نقاط ارتباطی میان نظام پیشنهادها و مدیریت دانش را به صورت شفاف تر و قابل برنامه ریزی ، جهت تعامل هدفمند میان این دو سیستم ، مشخص خواهد نمود .
مقدمه
در این مقاله سعی داریم بر مبنای نگرش سیستمی به موضوعات ، به جای اعمال تفکر و اگرا در خصوص نظام پیشنهاد ها و مدیریت دانش، تفکری همگرا را در این خصوص به کار بندیم. برای این منظور نخست تاریخچه ومفاهیم اساسی مرتبط با بحث های مدیریت مشارکتی و بالتبع آن نظام پیشنهاد ها و همچنین مدیریت دانش را مطرح نموده و سپس با طرح ایده هسته های پیشنهادی سعی در تشریح ساز و کار تعامل نظام پیشنهادها و مدیریت دانش خواهیم داشت . در صورت اجرایی شدن این ایده در یک سازمان علاوه ب آنکه امکان مشارکت تعداد بیشتری از کارکنان جهت استقرار سیستم مدیریت دانش فراهم می آید ، استقرار آن با سرعت بیشتر و هزینه کمتری امکان تحقق می یابد که ماحصل آن بهره وری بالاتر در این حوزه کاری خواهد بود .
تعریف مشارکت
( آلپرت 1945 ) مشارکت را « من فعال » تعریف می کند، برخی نیز مشارکت را تا سطح تفویض اختیار گسترش می دهند ( لوین 1986 ، ساکشین و موریس ، 1984 ؛ اشتراس و روزنشتین ، 1970 ؛ تاننبوم ، 1962 ؛ ) .
اما یک تعریف از مشارکت بر مبنای دیدگاه نظام مدیریت مشارکتی را که اختصار گویایی را توامان در برداشته باشد ، می توان چنین تعریف نمود :
« تعاون فکری افراد در راستای کسب موفقیت گروهی »
این همفکری افراد را تشویق می کند تا اهداف سازمان را اهداف خود دانسته ، مسوولیت دستیابی به عهده آنها را بر عهده گرفته و در اجرای موثر فعالیت ها سهیم باشند . به بیان دیگر مشارکت به معنای شرکت داوطلبانه و ارادی افراد در تصمیم گیری ها از طریق ارائه پیشنهادهای مفید و انجام و پیشبرد کارها در قالب فعالیت های گروهی در سازمان است .
مفهوم نظام مدیریت مشارکتی
یکی از نظام های مدیریتی پویا که نقشی بسیار مهمی در توسعه منابع انسانی و در نتیجه در فرآیند توسعه کلی يک سازمان دارد نظام مدیریت مشارکتی است . این نظام ، نظام همکاری فکری و عملی کارکنان يک مجموعه کاری با سطوح مختلف سازمانی است . در نظام مدیریت مشارکتی کلیه افراد سازمان درباره روش های حل مسایل و ارتقای بهره وری سازمان ، فعالانه اندیشیده و حاصل آن را در قالب طرح ها و پیشنهادها به سازمان ارائه می کنند . بدین طریق یک نظام همفکری و هم اندیشی برای رسیدن به اهداف سازمان به وجود می آید که به واسطه آن مدیریت سازمان ا گنجینه غنی دانش، تجارب، طرح ها، اندیشه ها و راه حل های ارائه شده توسط کارکنان برخودار و برای نیل به اهداف سازمانی از آنها بهره می جوید .
همچنین در این نظام برای خلاقیت های کلیه اعضای سازمان شایسته قائل شده و در تصمیم گیری ها از آنها استفاده می شود. دستاوردهای حاصل از استقرار نظام مدیریت مشارکتی از یک طرف می تواند موجب افزایش بهره وری در سازمان شود و از طرف دیگر سبب افزایش انگیزه ، افزایش تعلق خاطر کارکنان به سازمان ، افزایش خلاقیت، افزایش سطح دانش و آموزش افراد در قالبی خودجوش و مستمر شود .
از نظام پیشنهادها بعنوان ساده ترین ، رایج ترین و گسترده ترین ابزار مدیریت مشارکتی یاد می شود.اکنون مفهوم مدیریت مشارکتی به اختصار چنین ارائه می شود :
« مدیریت مشارکتی عبارتست از وجود آوردن فضا و نظامی توسط مدیریت که تمام کارکنان و مشتریان و پیمانکاران يک سازمان روند تصمیم سازی ، تصمیم گیری و حل مسایل و مشکلات سازمان با مدیریت همکاری و مشارکت نمایند .
همان گونه که از تعریف فوق بر می آید تاکيد اصلی این نوع مدیریت بر همکاری و مشارکت داوطلبانه کارکنان و مشتريان و پيمانکاران است و می خواهد از ایده ها ، پیشنهادها ، ابتکارات ، خلاقیت ها و توان فنی و تخصصی آنها در حل مسایل و مشکلات سازمان استفاده نماید .
تاریخچه نظام پیشنهاد ها
 موضوع مشارکت مردم در امور مختلف و تلاش برای حل مسائل و مشکلات گوناگون جوامع بشری از طریق همکاری و همفکری دسته جمعی افراد ، سابقه ای دیرینه دارد و به آغاز خلقت بشر بر می گردد زیرا تردیدی نیست که با پیدایش و تشکیل نخستین خانواده ها بر روی کره زمین ، افراد هر خانواده ناگزیر بوده اند مسائل و مشارکت و همکاری با یکدیگر برطرف نمایند .
با گذر زمان وگسترش جوامع بشری نیاز افراد به مشارکت در اشکال گوناگون افزایش یافت واستفاده از این موضوع در سازمان ها نیز ضرورت پیدا کرد . اما مساله مشارکت کارکنان در امور کارخانه ها از اواخر قرن نوزدهم ، به عنوان یک ایده مطرح شد و در سالهای بعد از جنگ جهانی اول به طور به طور جدی مورد توجه قرار گرفت . آغاز به کارگیری نظام پیشنهادها در قالب نظام مند فعلی به سال 1880 در ایالت متحده آمریکا بر می گردد . هنگامی که یال و تون کارخانه تولیدی خود را افتتاح نمودند و برای اولین بار طرح پیشنهادها را ثبت رساندند .
در ابتدای نظام پیشنهادها به عنوان یک تکنیک مدیریتی در افزایش کارآی و سود سازمان در ایالات متحده با نگاه ويژه به اثرات مالی پیشنهادها مرسوم گردید. بعد از جنگ جهانی دوم ، ژاپنی ها با این سیستم در صنایع آمریکا آشنا شدند وکم کم آن را در صنایع خود تزویج دادند با این تفاوت که در ژاپن بیشتر بر جنبه های مشارکتی نظام پیشنهاد ها با هدف افزایش روحیه کارکنان تاکید داشتند . پس ازآن بود که به تدریج سایر کشورها نیز با نظام پیشنهادها و مزایای آن بیشتر آشنا شدند و سعی در برقراری آن در سازمان ها و شرکت ها نمودند .
در ایران نیز برای نخستین بار نظام پیشنهاد ها در سال 1366 در شرکت رادیاتور سازی ایران استقرار یافت . همچنین به دنبال بازدید تعدادی از صنعتگران کشورمان از شرکت های ژاپنیدر اواسط دهه 1360 ، تصمیم گرفته شد این سیستم به صورت آزمایشی در چند شرکت استفاده شود . با توجه به نتایج مثبت حاصل از اجرای آن نهایتاً در سال 1379 شورای عالی اداری ، کلیه سازمان ها ، وزراتخانه ها ، بانک ها ، بیمه ها و شرکت های دولتی را موظف نمود تا پایان سال 82 نسبت به استقرار نظام پذیرش وبررسی پیشنهادها اقدام نمایند.
مفهوم نظام پیشنهادها
Suggest در لغت به معنی اظهار عقیده و پیشنهاد کردن آمده است و suggestions System به معنی نظام پیشنهاد ها در مباحث مدیریت مشارکتی به کار رفته است .
نظام پیشنهاد ها ، تکنیکی است که از طریق آن می توان به یافته های ذهنی و اندیشه سزمایه انسانی جهت حل مسائل موجود ، ایجاد سولات جدید و راه حل های بهینه در راستای فرهنگ بهبود مستمر سازمان دست یافت .
نظام پیشنهاد ها یا طرح بسیج اندیشه ها ، یکی از روشهای موثر در تغییر شرایط کار و ایجاد زمینه مناسب برای مشارکت کارکنان می باشد . نظام پیشنهاد ها یا کازین فردی ، نقش استمرار نوآوری و بهبود در سازمان ، با هدف نهادینه شدن رهبری در سازمان و برقراری ارتباط پايين تر سطح سازمان، با هدف نهادینه شدن رهبری در سازمان و برقراری ارتباط پايین ترین سطح سازمان با بالاترین سطح آن را ایفا می کند و معمولاً تمام کارکنان سازمان را شامل می شود .
فلسفه بنیادی نظام پیشنهاد ها بر این اساس استوار است که هر کاری بوسیله انسان انجام میشود هرگز کاملترین و بهترین شکل خود را ندارد بلکه همیشه این امکان وجود دارد که آن را با کارآیی و اثر بخشی بیشتری انجام شود . در بیان فلسفه به کارگیری نظام پیشنهادها به موارد زیر اشاره شده است :
سازمان رفتار کاری روابط بهبود جمعی همکاری مشارکتی فرهنگ اشاعه
لازم به ذکر است که محدوده عمل کارکنان در ارائه پیشنهاد موضوعات متنوعی نظیر موارد مندرج در ذیل می تواند باشد :
  • بهبود روش های انجام کار v بهبود ایمنی کار
در این قسمت به اختصار برخی دیدگاه ها و مبانی نظری مرتبط با بحث نظام مشارکت / نظام پیشنهاد ها ارائه می شود :
  • لی پرستون و جیمز پست بر این باور بودند که سه انقلاب در تاریخ مدیریت روی داده است :
    انقلاب اول با سلسه مراتب سازمانی
    انقلاب دوم در ارتباط با جدایی مالکیت از مدیریت
    و در حال حاضر ، مشارکت به عنوان سومین و مهمترین انقلاب در مدیریت
  • کورت لوین دانشمند برجسته آلمانی در پژوهش های خود متوجه شد ، هرگاه مردم در کارها مشارکت داده شوند ، اندازه مقاومت و ایستادگی آنان در برابر تغییر ، تحول ، نوسازی و نوآفرینی کاهش یافته و راه سازگاری در پیش می گیرند .
  • نظام پیشنهاد ها سیستمی است که بتواند زمینه لازم را برای حضور و مشارکت فعال تمامی کارکنان از مرحله آموزش و دریافت فرمهای پیشنهاد تا اعلام نتایج نهایی و اجرای پیشنهادها ، بدون پدید آمدن هیچمانع بازدارنده ای فرآهم آورد . ( غلامرضا خاکی )
  • کلارک ، فتچل و راترنر ( 1927 ) ، واکر ( 1974 ) و الیوت ( 1978 ) : مشارکت را یک فرآیند مورد توافق می دانند که از طریق آن کارکنان قادرند بر تصمیمات مدیریتی اثر بگذارند . رابطه نظام پیشنهادها با بهره وری : رابطه نظام پیشنهادها با بهره وری در نمودار زیر نشان داده شده است .
از جمله این مزایا عبارتند از :
  1. کارکنان را ترغیب می کند تا از دانش و تجربه خود در زمینه بهره وری در محیط کار استفاده کنند و آن را از قوه به فعل درآورند.
  2. موجب رشد و شکوفایی خلاقيت کارکنان و توانایی آنها در پرداختن به مسائل مختلف سازمانی خواهد شد .
  3. دانسته های مجموعه مدیریت سازمان را در مورد کار و تمایلات کارکنان افزایش می دهد .
  4. مدیریت به قابلیتهای افراد پی می برد و آنهایی که از توانایی بالا برخورد دارند شناسایی می کند .
  5. باعث ایجاد همدلی بین کارکنان و رده های مختلف سرپرستی و مدیریت می شود .
  6. بهبود کیفیت امور .
  7. سریع تر انجام شدن کارها
  8. کاهش هزینه ها و صرفه جویی اقتصادی . . .
 

مهندسي امنيت در 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.) ببينيد .
 

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

 
به کارگيري ملاحضات امنيتي در طي چرخه زندگي نرم افزار مي تواند امنيت نهايي نرم افزار وب را افزايش دهد . در اين بخش مراحل فعاليتهاي مربوط به امنيت بيان شده و يک روش کارا و موثر در طراحي ، پياده سازي و تست ارائه گرديده است . در اين بخش روشي ارائه مي گردد که امنيت برنامه هاي کاربردي تحت وب را با يکپارچه کردن امنيت و چرخه زندگي نرم افزار بهبود بخشد . ايده اي که در اين بخش ارائه مي گردد بر مبناي صدها سناريوي مشتريان در دنياي واقعي با محدوديت ها و ملاحضات امنيتي دنياي واقعي مي باشد .
مسير اثبات
سوالاتي که در امنيت نرم افزار تحت وب مطرح مي شود عبارتند از
  • آيا راهي وجود دارد که امنيت web application را از يک روش قابل تکرار افزايش دهيم ؟
  • آيا راهي وجود دارد که شاغلين را به مهارت هاي اثبات شده امنيت نرم افزار متصل کنيم ؟
  • آيا شيوه اي وجود دارد که بتواند بر اساس پروژه يا تيم scale up يا scale down شود ؟
  • آيا روشي وجود دارد که به صورت افزايشي ��ابل تطبيق باشد ؟
براي اينکه بتوان به درستي به موفقيت رسيد بايد ابتدا روشهاي خطا را شناخت . در اين مقاله ابتدا يک مجموعه از شيوه هايي که به درستي عمل نمي کند بررسي خواهد شد . سپس يک شيوه موفق تر معرفي مي گردد . اين شيوه مي تواند به سادگي براي سناريوهاي مختلف مناسب سازي شده و بسط داده شود . شيوه هايي که درست کار نمي کند در صورتي که چيزي شکسته نشده است آن را تعمير نکن . مساله اين است که ممکن است چيزهايي وجود داشته باشد که کار نمي کنند و يا اينکه کارايي لازم را ندارند ولي شما از آن اطلاع نداريد .اجازه دهيد که نگاهي به برخي از شيوه هاي شکست خورده و علت شکست آنها را بررسي کنيم .
شيوه Bolt-on
فلسفه اين شيوه اين است که ابتدا چيزي را بساز که کار کند و سپس آن را اصلاح کن . اين روش احتمالا معمول ترين روش براي امنيت مي باشد و تقريبا هميشه منجر به شکست يا عدم کارايي مي شود .
نتيجه اين روش اين است که در طي چرخه توليد نرم افزار از امنيت تا پايان که معمولا فاز تست مي باشد صرف نظر کن و سپس سعي کن که اشتباهات امنيتي را که قبلا در چرخه توليد رخ داده است برطرف کن . در اين شيوه فرض بر اين است که شما امنيت کافي مورد نياز را در پايان کار مي توانيد به دست آوريد .
عيب اصلي روش blot-on اين است که برخي از تصميمات بسيار مهم طراحي که بر روي امنيت تاثير گذار مي باشد در بقيه طراحي نرم افزار اثر آبشاري دارد . در صورتي که شما تصميمات ضعيف در ابتداي طراحي بگيرد شما در آينده مجبور به انتخاب هاي ناخواسته در آينده خواهيد شد . يا مجبور مي شويد که سطح امنيت نرم افزار را تنزل دهيد و يا اينکه deadline هاي پروژه را زير پا بگذاريد . در صورتي که شما تصميمات مهم امنيتي را در پايان توليد نرم افزار بگيريد چگونه مي توانيد مطمئن شويد که شما يک نرم افزار منطبق با اهداف خود پياده سازي و تست نموده ايد ؟
شيوه Do-it-all-up-front
عکس شيوه bolt-on شيوه do-it-all-upfront مي باشد . در اين شيوه شما سعي مي کنيد با همه نگراني هاي بالقوه امنيتي را در ابتدا برخورد کنيد .
اين شيوه ممکن است در دو سناريوي مختلف دچار شکست شود . نتوانيد اين کار را در ابتدا انجام دهيد و نا اميد شده و آن را رها کنيد .
فکر کنيد که همه موارد را تحت پوشش قرار داده ايد و ديگر سراغ امنيت نرويد تا زماني که يک آسيب پذيري را در يک محصول release شده مشاهده کنيد .
با وجود اينکه انجام ملاحظات امنيتي در ابتدا يک روش عاقلانه است اما نبايد انتظار داشت که همه چيز را پوشش دهد . زيرا اولا شما همه چيز را در ابتدا نمي دانيد . مهمتر از آن اين شيوه نمي تواند تصميماتي را که شما در طي چرخه زندگي نرم افزار مي گيريد و بر روي امنيت تاثير گذار مي باشد پيش بيني کند .
شيوه Big-bang
شبيه شيوه do-it-all-in front شيوه big-bang به شيوه اي گفته مي شود که شما در يک زمان تلاش و فعاليت زيادي را براي رسيدن به همه اهداف امنيتي خود انجام مي دهيد . بسته به اينکه شما در چه زماني اين تلاش را انجام مي دهيد شما قطعا مي توانيد به يک سري اهداف امنيتي برسيد .
يک سناريوي ممکن اين است که شما امنيت را تا فاز تست به تاخير بيندازيد و در اين فاز تلاش وسيعي را جهت ايجاد امنيت بر روي زير ساختي که ملاحضات امنيتي در آن لحاظ نشده است انجام دهيد .
روش buckshot
در اين روش شما سعي مي کنيد که خوشه اي از تکنيک هاي امنيتي را در برنامه کاربردي خود به کار بريد ، با اميد به اينکه به گونه اي مديريت را انجام دهيد که به بک هدف درست برسيد . در اين روش معمولا شما مواردي مانند اينکه کجا امن مي باشد ، کجا firewall داريم ، کجا از SSL استفاده مي کنيم را مي شنويد . در اين شيوه نشان دار کردن شما نمي دانيد هدفتان چيست و تلاش ها معمولا در يک مسير اشتباه و يا بدن سود انجام مي گيرد . مواظب افرادي که در زمينه امنيت تعصب دارند و همه کار را به سرعت بر روي ابزارهاي خود به کار مي برند بدون تهديدات واقعي که بايستي با آن مقابله کنند را بدانند . امنيت بيشتر لزوما به معني امنيت خوب نمي باشد . در واقع شما ممکن است يک trade off بين قابليت استفاده ، قابليت نگهداري ، performance و امنيت داشته باشيد .
ضرورتا شما نمي توانيد به امنيتي که مي خواهيد برسيد بدون اينکه يک هدف امنيتي خاص داشته باشيد . آتش گشودن دائم (حتي با اسلحه مناسب) موجب نمي شود که شما به هدفتان برسيد . شما چيزها را خواهيد کشت ولي چه کسي مي داند آنها چه چيزي هستند
شيوه all–or–nothing
در اين شيوه ممکن است شما هيچ کاري براي رسيدن به امنيت انجام نداده باشيد و حالا بخواهيد همه کار انجام دهيد . رسيدن به يک خرابي ممکن است دليلي باشد که شما بين اين دو شيوه سويچ کنيد .
روش هايي که کار مي کنند در صورتي که گذاشتن امنيت در بالاي برنامه کاربردي که در شيوه buckshot انجام شد نتايج موثري را ايجاد نمي کند چه شيوه اي کار مي کند ؟ پاسخ شيوه چرخه زندگي يا پختن امنيت در چرخه زندگي application مي باشد . با استفاده از اين روش شما امنيت را در چرخه توسعه نرم افزار به کار مي بريد به جاي آنکه آن را در در ابتدا ، بعد از يک اتفاق و يا به صورت تصادفي به کار ببريد . پختن امنيت در چرخه زندگي همچنين راهي براي ايجاد تعادل آن با ساير ويژگيها نظير performance ، flexibility و يا usability مي باشد .
چگونه مي توان اين کار را انجام داد . پاسخ اين سوال به اين صورت است که کدام يک از فعاليت هاي توسعه موثر ترين نتايج را در بر خواهد داشت .
بالاترين برگشت سرمايه
چگونه شما مي فهميد که از چه تکنينکي براي شکل دادن به نرم افزار در طي چرخه توليد استفاده کنيد ؟ با بالاترين نرخ بازگشت سرمايه به عنوان يک Baseline شروع مي کنيم . هر يک از شرکت هاي توسعه نرم افزار نوعي از اينگونه فعاليت ها را مستقل از تمرکز بر روي امنيت دارند .
  • راهبردهاي طراحي
  • مرور زيرساخت و طراحي
  • مرور کد
  • تست
  • مرور استقرار
راهبردهاي طراحي شامل توصيه هايي براي تيم توسعه مي باشد . اين توصيه ها تصميمات مهندسي کليدي را در بردارد (مانند مديريت استثنائات) و شامل توصيه هايي از فروشنده نرم افزار ، سياست هاي سازمان ، تجربيات صنعتي ، الگوها و ... مي باشد . اين يک فعاليت مهم در ROI مي باشد . زيرا چهارچوب نرم افزار را مشخص مي کند .
بررسي تحليل و طراحي کاري است که شامل طراحي براي نيازمنديهاي عملياتي ، نيازمنديهاي غيرعملياتي ، نيازمنديهاي تکنيکي و محدوديتها مي باشد که مي تواند به سادگي طرح کلي بر روي white board و يا شامل چندين مستند ، دياگرام و يا ارائه باشد . يک مرور تحليل و طراحي زماني مي تواند مفيد باشد که به اندازه کافي زود انجام شود تا بتواند به برنامه کاربردي شما شکل دهد .
مرور کد يک روش کاربردي و موثر براي پيدا کردن جنبه هاي کيفيت مي باشد . با وجود اينکه در برخي از زمينه ها شما مي توانيد ابزارهاي مرور کد پيدا کنيد مزيت مرور کد دستي بررسي مفهومي کد مي باشد .
تست يک فيدبک از نرم افزار قابل اجرا مي باشد . نرم افزار يا کار مي کند و يا کار نمي کند . فهميدن اينکه آيا نرم افزار درست کار مي کند مشکل تر است . حالت ايده آل اين است که شما يک قرارداد قابل اجرا بين کد و انواع مختلف نيازمندي ها و محدوديتها داشته باشيد .
اين مي تواند به شما کمک کند که شما به دنبال چه چيزي هستيد تا بتوانيد آن را تست کنيد .
رور استقرار ارزيابي برنامه کاربردي که بر روي زيرساخت مستقر گرديده است – جايي که لاستيک بر روي جاده قرار دارد آنجا جايي است که شما تاثير تنظيمات پيکربندي در برابر رفتار در حال اجرا را مي توانيد ارزيابي کنيد . مرور استقرار آخرين نقطه بررسي محصول مي باشد .
اين فعاليتها يک نرخ بازگشت سرمايه بالا را پيشنهاد مي کند که در صورتي که به درستي انجام گيرد در طي فرايند شکل نرم افزار را تحت تاثير قرار مي دهد .
مهندسي امنيت در فعاليت هاي baseline
شما مي توانيد يک سري فعالتيهاي موثر امنيت بر مبناي نرخ بالاي ROI ايجاد نمائيد . ولي به جاي اينکه امنيت را در فعاليتهاي موجود پراکنده کنيد آن را در فعاليتهاي خود ضرب کنيد . اين کار کمک مي کند که تلاشهاي امنيتي خود را بهينه نموده و يک چهارچوب لاغر براي بهبود مهندسي خود ايجاد نمائيد . با اثر گذاري امنيت در طي چرخه توسعه شما مي توانيد مجموعه اي از فعاليتهاي مرتبط با توسعه را پوشش دهيد .
جدول 1 فعاليتهاي کليدي امنيتي را در رابطه با فعاليتهاي استاندارد توسعه نشان مي دهد .
در بخش زير يک مجموعه از فعاليتهاي اصلي براي مهندسي امنيت آمده است :
  • اهداف
  • مدل سازي تهديد
  • راهبردهاي طراحي
  • مرور زيرساخت و طراحي
  • مرور کد
  • تست
  • مرور استقرار
اين فعاليتها يکديگر را تکميل نموده و اثر هم افزايي در امنيت نرم افزار دارند .
 
 

آخرین نظرات

Comment RSS