۱۳۹۰ مرداد ۲۳, یکشنبه

معماری سازمانی و معماری امنیت

بعد از مدتها غیبت می خوام توی این پست خلاصه ای از یافته های تزم رو بگم. موضوعی که روش کار کردم معماری امنیت و ارتباطش با معماری سازمانی بود. راستش انگیزه زیادی برای اینکار وجود داشت با توجه به تجربیات قبلی. امنیت یکی از دغدغه های مهم سازمانهاست و معماری سازمانی هم به عنوان یک چارچوب در سازمند کردن دغدغه ها باید بهش بپردازه. خصوصا چارچوبهای معماری سازمانی که برای پاسخگویی به دغدغه های ذینفعان اغلب مولفه ای رو پیش بینی کردند بایستی امنیت رو هم پوشش بدند به شکل مناسبی. توی پروژه هایی که قبلا توی ایران اجرا می کردیم همیشه سازمانها می گفتند امنیتش کجاست؟ ما هم اگه بر اساس دودف کار می کردیم می گفتیم توی همه محصولات امنیت مورد توجه قرار گرفته ولی بازم همیشه می گفتند خوب میشه یه جا جمعش کنید و نشون بدید بالاخره امنیت ما رو چجوری دیدید. و همیشه ما جواب درستی نمی تونستیم بدیم. حوزه امنیت یه جورایی استانداردهای خودش رو داره و به دلایلی مدیریتش هم جداگانه دیده میشه. چون اینکه چه کسی به چه اطلاعاتی دسترسی داشته باشه یه جورایی قدرت می ده به اون فرد یا واحد سازمانی و به همین دلیل مساله امنیت فقط یه موضوع تکنیکی نیست و یه مساله سیاسی هم هست توی سازمانها. شاید به همین دلیله که برخورد چارچوبهای مختلف معماری سازمانی با امنیت متفاوته. برخی از چارچوبهای معماری سازمانی امنیت رو بطور صریح یک مولفه تعریف می کنند مثل چارچوب دی ان دی ای اف و برخی چارچوبهای دیگه مثل دودف در متن سایر محصولات بهش می پردازند. من توی تزم روی این موضوع متمرکز شدم که اصلا معماری امنیت از کجا اومده و چارچوبهای مختلف چجوری دیدند امنیت رو و اینکه چرا این نگاه چند گانه به معماری امنیت وجود داره و نهایتا هر یک از رویکردهای موجود به امنیت چه نتایجی برای سازمانها می تونه در بر داشته باشه. اینکه معماری امنیت از کجا اومده رو میشه با بررسی تاریخچه معماری امنیت فهمید. این واژه از دهه 70 و 80 هم با مفهوم تکنیکی مورد استفاده قرار گرفته که بیشتر بحث معماری امنیت شبکه و پایگاه داده مورد نظر بوده و مفهوم معماری امنیت به عنوان یک رویکرد جامع در یکپارچگی امنیت بعد از مطرح شدن معماری سازمانی توسط زکمن مورد توجه قرار گرفته و اولین بار در اوایل دهه نود توسط وزارت دفاع ایالات متحده معماری امنیت به عنوان یک طرح جامع امنیت که توش از راهبردهای امنیت فناوری اطلاعات تا سازماندهی مسولیتهای امنیت و رویه های امنیتی بحث شده. بنابراین معماری امنیت با این مفهومش یه جورایی متاثر از معماری سازمانیه. ولی سوال اینجاست که چرا مثل بقیه معماری ها مثل معماری داده، معماری سیستم و معماری شبکه به عنوان یک زیرمعماری استاندارد در نیومده و هر چارچوبی یه جور باهاش برخورد کرده. من 2 تا تحلیل دارم برای این موضوع: 1- معماری امنیت ضرورتش بعد از معماری های دیگه احساس شده چون اولین دغدغه ایجاد سیستمهای یکپارچه و ایجاد دسترسی توسط شبکه های اطلاعاتیه و دغدغه امنیت یه جورایی از نظر زمانی بعد از ایجاد سیستمها بطور جدی احساس می شه. 2- مسئله امنیت ابعاد غیر فنی زیادی داره و تا حدی سیاسی-فرهنگی هم محسوب میشه و حتی ملیتهای مختلف برخورد متفاوتی باهاش دارند پس تعریف اون به صورت استاندارد مشابه معماری داده و سیستم به راحتی امکان پذیر نیست و اصولا امنیت در هر محیط و سازمانی باید بطور بومی تعریف بشه. بنابراین با مقوله معماری امنیت برخوردهای مختلفی شده. بر اساس یافته های مرور ادبیات بطور کلی چند رویکرد در تدوین معماری امنیت میشه مشاهده کرد. 1- رویکرد تدوین معماری امنیت بطور یک فرآیند مستقل از معماری سازمانی که معمولا در سازمانهایی اتخاذ میشه که سازمان مدیریت امنیت فاوا در اونها مستقل از مدیریت سیستمها و ... است. 2- رویکرد تدوین معماری امنیت مرتبط با معماری سازمانی که خودش چند شکل مختلف داره : 2-1- استفاده از مفاهیم معماری سازمانی برای تعریف معماری امنیت (مثلا استفاده از چارچوب زکمن برای تعریف چارچوب معماری امنیت) 2-2- استفاده از محصولات معماری سازمانی برای تدوین معماری امنیت و 2-3- تدوین معماری امنیت به عنوان بخشی از معماری سازمانی. در این رویکرد اخیر هم چارچوبهای معماری هم که برای مسائل و سازمانهای مختلف ایجاد شدند برخورد متفاوتی داشتند با این مقوله. اگه برای دسته بندی رویکرد چارچوبها از متاچارچوب گرم استفاده کنیم میشه گفت چارچوبها امنیت رو در خود چارچوب، متدولوژی معماری، متامدل معماری، محصولات معماری و ... مورد توجه قرار دادند. مثلا چارچوب دودف در متامدلش به امنیت پرداخته و دی ان دی ای اف براش محصول هم داره و یا ای تو ای اف فقط بعنوان یک مولفه در چارچوب معماری به امنیت پرداخته. هر کدوم از این استراتژیها می تونند پیامدها و دستاوردهای متفاوتی برای سازمانها داشته باشند که در تز بطور مفصل بحث کردم و اگه علاقه مند بودید بحثش رو ادامه می دم

۳ نظر:

ناشناس گفت...

salam hatman edame bedid

محمدحسین گفت...

خیلی خوشحالم که بالاخره به‌روز کردید.

این که معماری امنیت چرا کمتر به صورت مستقل دیده شده، آیا ناشی از این نیست که یک جور جنبه‌ی سراسری (cross-cutting aspect) هست و نه یک مؤلفه‌ی شسته رُفته؟ مثل دیدگاه‌های Standard و Project و Data در اون شکل معروف دیدگاه‌های DoDAF:
http://cio-nii.defense.gov/sites/dodaf20/images/clip_image002_0010.gif

یعنی به صورت یک لایه‌ی افقی نمی‌شه مطرحش کرد. خب البته دیدگاه‌های معماری داده و پروژه هم همین‌طوری هستند ولی خب اون‌ها همان‌طور که گفتید برای دغدغه‌های رایج مدیریت سیستم‌ها این‌ها اولویت بیشتری دارند. (یه مقاله هم در این زمینه هست که البته من هنوز نخوندمش: http://wwwmatthes.in.tum.de/file/Publications/2010/Bu10q.pdf)
من با این موضوع مدل‌سازی جنبه‌گرا (aspect-oriented) که اول در مهندسی نرم‌افزار مطرح شده، تازه آشنا شدم و به نظرم برای رفع خیلی از مشکلاتی که توی مدل‌سازی معمولی پیش میاد رویکرد قدرتمندیه.

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

علی فتح‌اللهی گفت...

علاقه-مند بودیم. ادامه بده. ولی اگه میشه کوتاهتر بنویس