امنیت نرم افزار

در این بخش ابتدا به بیان مفاهیم بنیادی امنیت با ارائه چند تعریف عام و خاص از آن می­پردازیم و پس از کسب شناخت کافی از مفهوم امنیت مجدداً به معماری سرویس­گرا و نیازهای امنیتی آن برخواهیم گشت سپس امنیت و استانداردهای امنیتی را در معماری سرویس­گرا مورد بررسی قرار      می­دهیم.

2-3-1 مفاهیم پایه­ای امنیت

دانش عمومی «امنیت» را وضعیتی بدون خطر[1] و ریسک[2] تعریف می­کند. به عبارتی وضعیتی فارغ از شبهه، تشویش یا نگرانی است. امنیت رایانه محدود است به توصیف شاخه­ای از علم کامپیوتر که با ریسک­ها، تهدیدها و مکانیزم­های مربوط به استفاده از سیستم­های محاسباتی سروکار دارد[27]. مفهوم امنیت در سیستم­های رایانه­ای اولیه که اغلب به صورت متمرکز بودند چندان اهمیتی نداشت. با گسترش استفاده از رایانه و چند کاربری شدن، نیاز به امنیت پررنگ­تر شد[28].

حال می­خواهیم بدانیم هدف از تعبیر امنیت در حیطه نرم­افزار چیست. اهداف امنیتی را می­توان مشخصه­ها و جنبه­هایی برای تضمین امنیت که توسط یک مدل دنبال می­شود دانست. دیدگاه­ها و نظرات مختلفی برای اهداف امنیتی در نرم­افزار وجود دارد. به عنوان مثال از دیدگاه بیوشاپ[3] سه جنبه اساسی از امنیت رایانه عبارتند از: رازداری، جامعیت و دسترس­پذیری[4] [27]. در دیدگاهی دیگر، منزس[5] هفده هدف اساسی برای امنیت اطلاعات بیان کرده است که در بین آن‌ها اهدافی مانند رازداری، جامعیت، تعیین هویت[6] و اعتبارسنجی وجود دارد[27]. آقای هفنر[7] در [27] استنباط می­کند این اهداف امنیتی از چهار آرمان نهفته رازداری، جامعیت، اعتبارسنجی و عدم-انکار[8] مشتق شده­اند. در برخی منابع، اصول و اهداف امنیتی را از هم جدا نمی­دانند یا حداقل، برخی از اهداف امنیتی و اصول آن­را مشترک می­دانند. در [29] هفت اصل امنیتی به عنوان مبنایی برای یک راه­حل امنیتی مناسب در نظر گرفته شده­است که عبارتند از : اعتبارسنجی، اختیارسنجی، جامعیت، دسترس­پذیری، رازداری، ممیزی و عدم انکار. برخی از این اهداف با جنبه­های وظیفه­مندی امنیت مشترک هستند. این جنبه­ها طبق[30] شامل: اعتبارسنجی، اختیارسنجی، رازداری داده­ها، حفاظت در مقابل حملات و محرمانگی[9] هستند. اما آنچه در متون مختلف به عنوان اهداف امنیتی به طور مشترک آمده است همان سه هدف اساسی رازداری، جامعیت و دسترس­پذیری است [15, 27, 29, 30]. در ادامه هرکدام از این اهداف را به طور مختصر شرح می­دهیم.

رازداری: رازداری را عدم افشای اطلاعات برای فرآیندها، موجودیت­ها یا کاربران غیرمجاز تعریف می­کنند[29]. از طرفی در [27] رازداری هدفی است که در آن داده­ها باید تنها توسط موجودیت که مجوز مناسب دارد قابل خواندن باشد. در تعریفی ساده­تر رازداری «محافظت از پوشیدگی داده­های حساس» است[30]. به عبارتی می­توان گفت یکی از اهداف امنیت در راستای حفاظت از افشای داده­ها و توابع حساس سیستم برای کاربر و یا موجودیت غیرمجاز دربرگیرنده رازداری است.

جامعیت: ممانعت از تغییر یا تخریب یک منبع اطلاعاتی توسط کاربر یا موجودیت[10] غیرمجاز است[29]. به عبارتی جامعیت هدفی است که طی دستاوردهای آن داده­ها و اطلاعات نباید تغییر کنند مگر آنکه به طور صریح مجاز به تغییر باشند[27]. یعنی جامعیت تضمین می­کند که محتوای پیام از لحظه خروج از مبدأ تا تحویل به گیرنده در مقصد، تغییری نکرده است[15]. در رازداری اجازه داده نمی­شود که داده حساس توسط موجودیت غیرمجاز دیده شود، ولی در جامعیت اجازه تغییر و تحریف به موجودیت غیرمجاز داده نمی­شود.

دسترس­پذیری: به طور عام بیانگر آمادگی پیوسته سیستم به پاسخگویی درخواست­های معتبر و عدم انکار آن­ها می­باشد. اما در بعد امنیت بیانگر حفاظت از منابع سازمان در مقابل تهدیدات انکار سرویس­دهی است که ممکن است دسترس­پذیری سیستم را مورد تأثیر قرار دهد[29]. امنیت در اهداف رازداری و جامعیت خود، مانع تحریف و دسترس­های غیرمجاز به منابع و داده­های حساس سازمان می­شود و از سوی دیگر در هدف دسترس­پذیری خود بیان می­کند که نباید مانع دسترسی­های مجاز و پاسخ­دهی به درخواست­های معتبر شد و سیستم باید در هر حال برای پاسخگویی به این گونه درخواست­ها، در دسترس باشد.

برای دستیابی به هر کدام از این اهداف امنیتی می­توانیم از سیاست­های امنیتی که این اهداف را محقق می­سازد استفاده نمود.

2-3-2 سیاست­های امنیتی

اهداف امنیتی یک رده­بندی نوعی از آرمان­ها را فراهم می­کند که ممکن است برای رسیدن به نوع مشخصی از نیاز امنیتی سهیم باشند. آرمان امنیتی ممکن است بر اساس زمینه کاربردشان، معمولاً به دو صورت مطرح می­شوند: این دو گونه، سیاست امنیتی و نیازهای امنیتی هستند که در ادامه تشریح  می­کنیم. یک سیاست امنیتی، یک هدف امنیتی خاص یا ترکیبی از آن‌ها را محقق می­سازد که به این صورت تعریف می­شود: حکمی که مشخص می­کند چه چیزی مجاز و چه چیزی غیرمجاز است. سياست­هاي امنيتي به عنوان مدل­هاي نيمه رسمي تعريف مي­شوند. رسمي از آن جهت كه می‌توان آن‌ها را به صورتي بيان كرد كه براي پيكربندي مكانيز­م­هاي امنيتي توسط ماشين، قابل قرائت و فهم باشند، و غير رسمي از آن جهت كه تعريف رياضي براي آن‌ها ارائه نشده است. ايراد درستي كه بر سياست امنيتي وارد مي­شود اين است كه به دليل نيمه رسمي بودن، نمي­توان آن را به طور غير مبهم فرموله كرد. با اين وجود، ديدگاه مطرح شده فعلي، بيشتر بر جنبه­هاي اجرا پذیری و قابليت استفاده تاكيد دارد. يك سياست رسمي، ممكن است از دقت بالايي برخوردار باشد يا تنها راه اثبات صحت يك سياست در سطح مشخصي از دقت باشد، اما اين مزايا با يك هزينه سربار بسيار بالايي همراه باشد كه ممكن است در عمل چندان كاربردي نباشد. يك سياست كارا را بر اساس يك توافق عام و تفسير جامعه نرم­افزاري كه از آن استفاده مي­كند، تعريف مي­كنند. با اين حال، مدل­هاي رسمي هر جا كه لازم باشد، مي­توانند با بسترهاي مختلف يكپارچه شوند. در اساس، بين سياست­هاي امنيتي پايه­ای و سياست­هاي امنيتي پيشرفته تمايز وجود دارد. گونه دوم بر مبناي مدل رسمي سياست است[27].

به عبارتی سیاست امنیتی قواعد سطح بالایی است بر اساس این که چه کنترل دسترسی باید تنظیم شود. همچنین مدل امنیتی یک ارائه رسمی از سیاست امنیتی و عملکرد آن است.

2-3-3 نیازمندی­های امنیتی

در مقابل سياست امنيتي كه براي مديريت امنيت به عنوان مجموعه­اي از «چه چیزهایی مجاز و چه چیزهایی غیرمجاز است»، نيازمندي­هاي امنيتي روي مراحل اوليه مهندسی (مرحله جمع­آوري اطلاعات تمركز دارد). يك نيازمندي امنيتي، يك توضيح مفصلِ مستقل از زمينه براي يك هدف امنيتي است[27]. نيازمندي امنيتي يك هدف امنيتي را به چند توصيف مفصل­تر بر اساس نتايج تحليل امنيت، تقسيم مي­كند. نيازمندي­هاي امنيتي را مي­توان به دو كلاس كلي دسته­بندي كرد: نيازمندي­هاي   وظيفه­مندي و غيروظيفه­مندي[30]. جنبه­هاي وظيفه­مندي امنيت عبارتند از:

الف)  اعتبار سنجي  يا تشخيص صحت هويت کاربران.

ب) اختيارسنجي  يا تصميم بر دادن يا ندادن اختيار براي انجام يك عمل توسط كاربر شناخته شده روي يك منبع مشخص.

ج) رازداري داده­ها يا محافظت از محرمانه بودن داده­هاي مهم.

د) جامعيت داده يا تشخيص تحريف داده­ها و اطمينان يافتن از آنكه هيچ كدام از فرستنده يا گيرنده نمي­توانند داده ارسالي يا دريافتي را تغيير دهند.

ه) حفاظت در مقابل حملات يا اطمينان يافتن از آنكه مهاجم­ها نمي­توانند روي كاربرد، كنترلي به دست آورند.

و) پوشيدگي يا اطمينان از این که برنامه كاربردي، پنهان بودن داده­هاي كاربران را نقض نمي­كند.

جنبه­هاي غيروظيفه­مندي امنيت: اين جنبه­ها از آنجا كه به طور مستقيم با امنيت در ارتباط نيستند، غيروظيفه­مندي ناميده مي­شوند و عبارتند از [30]:

الف) قابلیت تعامل: این مفهوم مختص به معماری سرویس­گرا است و بیان می­کند که راه­حل­های امنیتی مختلف نباید سازگاری سرویس­ها را نقض کند.

ب) قابلیت مدیریت: نیاز است راه­حل امنیتی از سرویس­های مختلف محافظت کند. یک معماری امنیتی خوب، باید به راحتی قابل مدیریت باشد.

ج) سادگی در توسعه: این جنبه برای تمامی راه­حل­های امنیتی مشترک است. هر چقدر پیچیدگی توسعه راه­حل امنیتی بالاتر باشد، امکان تطبیق آن با معماری مربوطه کمتر خواهد بود.

در منبعی دیگر این نیازمندی­ها به طور خلاصه در پنج مورد خلاصه شده­اند: تعیین هویت، اعتبارسنجی، اختیارسنجی، رازداری و جامعیت[15].

2-3-3-1 نیاز امنیتی اعتبارسنجی

به طور معمول، يك درخواست به منبع از نگاه امنيتي با ادعاي يك هويت يا شناسه شروع می‌شود. درخواست­كننده با ارائه يك شناسه يا اعتبار، هويت خود را معرفي مي­كند. سيستم بر اساس   مكانيزم­هاي خاص، اين هويت را شناسايي مي­كند. اين همان فرآيند تعيين هويت است كه خود جزء نيازهاي امنيتي به شمار می‌آید، اما تعيين هويت به تنهايي كافي نيست. براي اطمينان از اينكه آيا هويت ادعا شده داراي اعتبار هست يا خير فرآيند مكمل ديگري بنام اعتبارسنجي نياز است. اعتبارسنجی فرآیندی است برای اثبات ادعای یک هویت ارائه شده. در فرآیند اعتبارسنجی، موجوديت يا كاربر درخواست كننده، همراه با شناسه خود، دليل يا مدركي ارائه مي­دهد تا گيرنده درخواست، اطمينان يابد كه ادعاي وي درست است[30].

2-3-3-2 نیاز امنیتی اختیارسنجی

اختیارسنجی که معمولاً آن­ را با کنترل دسترسی یکسان می­دانند عبارت است از «فرآیند تعیین مجاز یا غیرمجاز بودن درخواست یک موجودیت از یک منبع مشخص»[31]. در تعریفی دیگر، كنترل دسترسي به صورت فرآيند وساطت بين هر درخواست به منابع و داده هاي نگهداري شده توسط يك سيستم و تعيين اينكه آيا درخواست بايد تضمين شود يا انكار فرآيندي بيان شده است. در همان منبع، تعريف كامل­تری آمده است: «فرآیندی است براي اعمال حفاظت كه طي آن، هر دسترسي به سيستم و منابع آن بايد كنترل شود و همه و تنها دسترسي­هاي مجاز می‌توانند انجام شوند» [27].

اين در حالي است كه [31] نگاه ظریف‌تری به فرآيند كنترل دسترسي دارد و آن را به اين صورت تعريف می‌کند: فرآيندي است كه طي آن عمليات و دسترسي­هاي كاربر مجاز بر منابع سيستم كنترل مي­شود و بر اساس قواعدي در مورد مجاز بودن آن تصميم گرفته مي­شود. از تعريف اخير مي­توان دريافت كه كنترل دسترسی یا اختيارسنجي فرآيندي است كه بر مجموعه كاربران شناخته شده اعمال می‌شود. به عبارت ساده تر، اختيارسنجي هميشه بعد از اعتبارسنجي صورت می‌گیرد.

2-3-3-3 نیاز امنیتی رازداری

رازداري براي امنيت هم يك هدف به شمار می‌آید هم يك نيازمندي. منظور ما از نيازمندي رازداري «فراهم آوردن مکانیزم­هایی برای محفوظ ماندن داده­ها و اطلاعات حساس از دید موجودیت­های غیر­مجاز» است. از آنجا که در تبادل داده­ها در سیستم­های امروزی، به دلیل گستردگی و توزیع‌شدگی واسط­های زیادی بین فرستنده و گیرنده اطلاعات ایجاد شده­است، نیاز است آن‌ها را در برابر مهاجمان و استفاده­کنندگان غیرمجاز محافظت نمود. اين نياز، در قالب رازداري ديده مي­شود[30].   به عبارتي ديگر، نياز به رازداري زماني پررنگ‌تر مي­شود كه قرار است داده يا اطلاعات حساسي از يك مبدأ به مقصد معيني ارسال شود و در اين مسير ارسال، واسطه­هاي پيش­بيني شده يا مهاجمان پيش­بيني نشده­اي وجود خواهد داشت كه اين داده­ها براي آن­ها افشا شوند. با استفاده از سياست رازداري می‌توان وضعیت‌هایی را از سيستم تعيين نمود كه در آن تنها موجودیت‌های اعتبارسنجي شده می‌توانند به اطلاعات دسترسي يابند. چنين سياستي، نيازمندي امنيتي رازداري را برطرف می‌سازند. با اين حال اين سياست بر اعتبارسنجي و اختيارسنجي به عنوان ابزارهايي براي تحقق كنترل دسترسي تكيه دارد. در حالی که اعتبارسنجي مكانيزمي براي اثبات و شناسايي ماهيت يك موجوديت است، اختيارسنجي يك مدل امنيتي مشخص براي چگونگي تضمين امتيازات مختلف برای موجوديت­هاي اعتبارسنجي شده را محقق مي­سازد [27].

2-3-3-4 نیاز امنیتی حفاظت از داده

به طور معمول در فعاليت­هاي تجاري به واسطه قوانين يا قراردادها، افشاي اطلاعات محرمانه و شخصي مشتريان امري منع شده به شمار مي­آيد. اين ممنوعيت بايد در برنامه­هاي كاربردي كه براي خودكارسازي فعاليت­هاي تجاري انساني ايجاد شده‌اند، نيز اعمال شود[30]. به بياني ديگر، برنامه­هاي كاربردي تجاري، بايد با دقت طراحي، پياده­سازي و مديريت شوند تا از افشاي اطلاعات محرمانه كاربران جلوگيري شود. بنابراين يكي ديگر از نيازهاي امنيتي كه بايد در نظر گرفته شود، حفاظت از داده­ها و اطلاعات محرمانه افراد است. رازداري و حفاظت داده مفاهيم مشابهي را پوشش مي­دهند. تفاوتي كه بين آن­ها وجود دارد اين است كه در رازداري هدف پايبندي به حفظ محرمانگي داده­ها در تبادلات بين واحد­هاست. اما حفاظت از داده­هاي محرمانه اساساً بر عدم افشاي اطلاعات محرمانه تاكيد دارد.

افشاي اطلاعات محرمانه، به دو دليل اساسي اما ساده رخ می‌دهد[30]:

1) نقص در قواعد كنترل دسترسي: به عنوان نمونه در برنامه كاربردي آموزش الكترونيكي، شناسه دانشجوياني كه براي كلاس ثبت نام نموده­اند نبايد در معرض عام قرار گيرد و تنها مدير سيستم بايد مجاز به دسترسي به آن‌ها باشد. اين مورد ممكن است منجر به دسترسي­هاي ناصحيح توسط كاربران غيرمجاز شود. نقص در قواعد كنترل دسترسي را مي­توان با بازنگري دقيق و رسيدگي­هاي امنيتي برطرف نمود. به بياني ديگر، بايد قواعد كنترل دسترسي به نحوي تعريف شوند كه محدوده اختيارات

هر قاعده مشخص و محدود باشد. در غیر این صورت كاربران مجازي كه به آن‌ها دسترسي­هاي محدودي داده شده است، به واسطه تخصيص ناصحيح اختيارات به قواعد، مي­توانند اختيارات بيشتر از حد انتظاري را در سيستم داشته باشند. به عنوان نمونه در مورد انتساب ناصحيح اختيار به قاعده مي­توان به انتساب «امکان ویرایش نمرات دانشجو» به اختیار «مشاهده نمرات» اشاره کرد. در این حالت کسی كه داراي اختيار مشاهده نمرات باشد، مي­تواند آن‌ها را نيز ويرايش كند كه طبيعتاً اين مطلوب نخواهد بود.

2) آسیب‌پذیری‌های به كار گرفته شده توسط مهاجمان: آسیب‌پذیری‌ها به طور كل يا در كد برنامه كاربردي قرار دارند يا ناشي از ضعف در روش­هاي مديريتي هستند. به عنوان نمونه، خرابي در بررسي داده­هاي ورودي كاربران قبل از اعمال در سيستم، مي­تواند باعث شود كاربران بتوانند با استفاده از تزریق SQL، تغییر ناخواسته در اطلاعات مهم پایگاه داده ایجاد کنند. یا اشتباه در عدم تغییر کلمه عبور پیش فرض برای کاربر مدیر، تمامی دسترسی­ها روی داده­ها را برای مهاجمان باز می­گذارد. با استفاده از روش­هاي صحيح مديريتي، بررسي­هاي امنيتي و ابزار تشخيص تهاجم، مي­توان از اين مشكلات جلوگيري كرد[30].

2-3-3-5 نیاز امنیتی جامعیت

جامعيت يا يكپارچگي به طور ساده همان عدم تحريف داده­هاست. اين نياز در پاسخ به هدف جامعيت ديده شده­است. در [27] اين نياز به اين صورت بيان شده است: «هر سیستم اطلاعاتی لازم است از داده­ها و منابع در مقابل افشای غیرمجاز (محرمانگی) و تغییر غیرمجاز یا ناصحیح (جامعیت) اطلاعات پیشگیری نماید، درحالی‌که به طور هم­زمان، باید دسترس­پذیری برای کاربران مجاز را تضمین کند (اصل عدم انکار سرویس­دهی)». در سيستم­هايي مانند سيستم­هاي مبتني بر معماري سرويس­گرا كه تبادل اطلاعات از طريق پيام است، هنگامي كه يك برنامه كاربردي پيام يا اطلاعاتي را دريافت مي­كند، لازم است اطمينان حاصل شود كه اين پيام دقيقاً هماني است كه فرستنده ارسال نموده و در فرآيند تبادل، توسط يك واسطه غيرمجاز دچار تغيير نشده است [30]. سياست جامعيت راه­هاي معتبري كه اطلاعات ممكن است تغيير كند و ماهيت­هايي كه براي تغيير مجاز شوند را تعيين مي­كند. جامعيت را از دو ديدگاه بررسي مي­كنند: جامعيت داده‌ها و جامعیت مبدأ. جامعيت داده­ها تضمين مي­كند كه داده­ها در معرض خطر قرار نگرفته­اند و بنابراين در يك بازه زماني مشخص    مي­توان به آن اعتماد نمود، در حالی که جامعیت مبدأ تضمين مي­كند كه اطلاعات در مورد گيرنده پيام صحيح هستند. هردو گونه توسط مباني رمزگذاری پياده­سازي شده­اند. در اينجا كاربرد رمزگذاري همان امضاي الكترونيكي است[27].

به طور كلي، مانند رازداري پيام، جامعيت نيز از طريق به­كارگيري اصول رمزگذاري در سطح پيام تحقق مي­يابد.

2-3-2 امنیت و معماری سرویس­گرا

برنامه­های کاربردی سرویس­گرا نیاز دارند تا به منظور اداره بسیاری از نیازمندی­های امنیتی سنتی برای حفاظت از اطلاعات و اطمینان از آنکه دسترسی به منطق تنها برای آن‌هایی که مجاز هستند تضمین شده­است. اما اصول امنیت از نگاه آی.بی.ام[11] عبارتند از : هویت سنجی، اعتبارسنجی، اختیارسنجی، رازداری، جامعیت، بازرسی و تطبیق، مدیریت سیاست­ها و دسترس­پذیری. ضمن آنکه این اصول در هر معماری، از جمله معماری سرویس­گرا وجود دارند، از نظر آی.بی.ام برخی جنبه­ها و ملاحظات دیگر بین معماری سرویس­گرا و امنیت هستند که باید مورد توجه قرار گیرند. به دلیل ماهیت سست اتصال عناصر معماری سرویس­گرا و عملکرد آن­ها فراتر از مرزهای سازمانی، امنیت در این معماری دارای مشکلات بیشتری می­باشد؛ لذا باید ملاحظات زیر را در نظر گرفت[32]:

• امنیت یک نیازمندی کسب­وکار است نه یک تکنولوژی. یعنی نیازهای امنیتی نیز مانند نیازهای وظبفه­مندی یک کسب­وکار باید در مراحل مختلف خودکارسازی منطق راه­حل دیده شده و در مواقع لازم، اعمال شود.
• محیط معماری سرویس­گرا چالش­های امنیتی خود را به همراه دارد، و عبارتند از:
• نیاز به انتشار شناسه­های کاربران و سیستم­ها در طول محیط (مثلاً به منظور اعتبارسنجی یا اختیارسنجی). هر موجودیت در معماری سرویس­گرا یک شناسه برای اعلام هویت خود دارد؛ لذا باید این شناسه را از مفهوم سرویس تفکیک نمود.
• نیاز به مدیریت هویت و امنیت در بین طیف وسیعی از سیستم­ها و سرویس­ها که با ترکیبات مختلفی از تکنولوژی­ها و سیستم­های قدیم و جدید ساخته شده­اند.
• حفاظت از داده­ها در انتقال­ها تا رسیدن به مقصد.
• نیاز به اجابت اثبات پذیری[12] معماری در مقابل رشد مجموعه­های شرکت­ها، صنایع و استانداردهای تنظیم شده.
• امنیت باید به طور کامل چرخه­حیات توسعه معماری سرویس­گرا را ازجمله مراحل مدل­سازی، یکپارچه­سازی[13]، استقرار[14] و مدیریت برنامه­های کاربردی را احاطه کند (شکل2-7)[32].

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

در مرحله مدل­سازی سیاست­های امنیت کسب­و­کار باید تعریف شوند و نیازمندی­های امنیتی و ایمنی برنامه­های کاربردی مدل­سازی شود. موجودیت­های درگیر در این مرحله، متصدی سیاست­های امنیت[15]، بازرس امنیتی[16] و تحلیل­گر کسب­و­کار[17] هستند.

شکل 2-7 چرخه حیات معماری سرویس­گرا از نگاه امنیتی آی­بی­ام [32]

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

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

مرحله مدیریت به مدیریت برنامه­های کاربردی، مدیریت بر شناسه­ها و نظارت به منظور تطبیق تاکید دارد. در این مرحله موجودیت­هایی همچون مدیر فناوری اطلاعات، مدیر امنیتی و اپراتورها ایفای نقش می­کنند.

اما برای تحقق اهداف و نیازمندی­های امنیتی در معماری سرویس­گرا، شرکت آی­بی­ام یک معماری منطقی نیز ارائه داده است (شکل2-8). در این معماری سطوح منطقی مختلفی دیده می­شود که عبارتند از[32]:

• سرویس­های امنیتی کسب­و­کار: این سرویس­ها جنبه­های کلان و تجاری امنیت در سازمان را برای دستیابی به عملکرد موفق و ایمن در سازمان بیان می­کنند. این جنبه­ها بر اساس معیارهای مشخص در صنعت مانند قوانین، ضوابط رقابتی بین سازمان­ها و غیره می­باشند. به بیان ساده­تر این سرویس­ها به پرسش «به چه چیزی باید دست یافت؟» پاسخ می­دهند.
• سرویس­های امنیتی فناوری اطلاعات: بلوک­های سازنده به صورت مجموعه­ای از سرویس­ها برای فراهم نمودن وظایف امنیتی است. بنابراین سرویس­های امنیتی چگونگی دستیابی به تعاریف بیان شده در سرویس­های امنیتی کسب­و­کار را تحقق می­بخشند.

شکل 2-8 مدل مرجع امنیت معماری سرویس­گرا از آی­بی­ام [32]

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

همچنین دیدگاه­های دیگری نیز در رابطه با امنیت معماری سرویس­گرا موجود است. ارل در [15] نگاهی ساده­­تر و عملیاتی­تر به امنیت در معماری سرویس­گرا دارد. شاید در این دیدگاه امنیت تنها از نگاه پیاده­سازی و اعمال سیاست­ها دیده شده­است. او ادعا می­کند که : «به طور مشخص، امنیت سطح پیام به عنوان مؤلفه اصلی راه­حل­های سرویس­گرا می­باشد. اقدامات امنیتی می­توانند به صورت لایه­ای روی هر انتقال پیام قرار گیرد تا از محتوای پیام یا گیرنده پیام محافظت کند[15].»

بنابراین چارچوب WS-Security و توصیفات ملحق به آن، نیازمندی­های بنیادی کیفیت سرویس را انجام می­دهند تا سازمان­ها را قادر سازند که از راه­حل­های سرویس­گرا برای پردازش داده­های حساس و محرمانه خود استفاده کنند و همچنین دسترسی به سرویس را در هر جا و هر اندازه که لازم شد محدود کنند. همان‌طور که در شکل 2-9 نشان داده شده است چارچوب امنیتی WS-Security از چارچوب WS-Policy نیز استفاده می­کند.

شکل 2-9 جایگاه امنیت در معماری سرویس­گرا [15]

در مدلی که در[33] ارائه شده است، با در نظر گرفتن سه لایه اساسی برای معماری سرویس­گرا مبتنی بر وب­سرویس، جنبه­های امنیتی در سطح این لایه­ها توزیع و اعمال شده­است. همان‌طور که در شکل 2-10 مشاهده می­کنید، جنبه­های اعتبارسنجی و اختیارسنجی را می­توان در لایه­های امنیت فرآیند کسب­و­کار و امنیت وب­سرویس اعمال نمود.

شکل 2-10 لایه­های معماری سرویس­گرا و جنبه­های امنیتی[33]

[1] Danger

[2] Risk

[3] Bishop

[4] Confidentiality, Integrity and Availability (CIA)

[5]  Menezes

[6] Identification

[7] Hafner

[8] Non-Repudiation

[9] Privacy

[10] Actor

[11] IBM

[12] Demonstrable Compliance

[13] Assemble

[14] Deployment

[15] Security officer

[16] Security auditor

[17] Business analysis

[18] Distribution and transformation policies