1. مدل سازی کنترل دسترسی و مدیریت اعتماد در سطح معماری نرم افزار
مدل سازی کنترل دسترسی و مدیریت اعتماد در سطح معماری نرم افزار
ارائه دهنده : پویا جافریان
استاد راهنما : دکتر عبداله زاده
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

2. مقدمه – اهمیت امنیت در سیستم های نرم افزاری
در دهه اخیر سیستم های کامپیوتری در جنبه های مختلف زندگی انسان رسوخ کرده اند.
گسترش و وابستگی به سیستم های کامپیوتری اثرات منفی بر زندگی انسان ها داشته است.
یکی از اثرات منفی، گسترش روزافزون اشکالات امنیتی در سیستم های کامپیوتری، و حملات علیه این سیستم ها است.
بر اساس گزارش ارائه شده توسط CERT/CC ، در سال 2006 بیش از 8000 رخنه در سیستم های کامپیوتری گزارش شده است.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

3. تعداد رخنه های سیستم های کامپیوتری
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

4. تعداد حملات علیه سیستم های کامپیوتری
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

5. مشکلات امنیتی و مقابله با آنها
علل گسترش روز افزون مشکلات امنیتی
ساخته شدن نرم افزار از اجزاء مختلف و جدا از هم
استقرار نرم افزار در محیط های توزیع شده و گسترده
روش های کلاسیک امنیت سعی در پیشگیری مشکلات امنیتی با ارائه راه حل های رمز نگاری دارند.
با این وجود عمده حملات انجام شده به علت طراحی ضعیف و غلط نرم افزار است.
بنابراین روشی مهندسی برای طراحی صحیح نرم افزار باید ارائه شود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

6. مهندسی نرم افزار راه حل مقابله با مشکلات
مهندسی نرم افزار یک تکنولوژی لایه ای با هدف تولید سیستم با کیفیت است[Pressman03].
اولین مرحله ای در تولید نرم افزار که در آن به ویژگی های کیفی در تولید سیستم توجه می شود، معماری نرم افزار است[Bass03].
معماری نرم افزار شامل اولین تصمیمات طراحی سیستم است.
معماری نرم افزار اولین عنصر قابل ارزیابی در تولید سیستم است.
بنابراین معماری نرم افزار، اولین گام در دستیابی به امنیت می باشد.
به عنوان مثال در نرم افزار IIS با تغییر در معماری نرم افزار و بدون معرفی تکنولوژی های جدید، مشکلات عمده امنیتی برطرف گردید[WING03] .
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

7. روش طراحی معماری نرم افزار
برای طراحی معماری نرم افزار نیاز به :
تاکتیک معماری
الگوی معماری
تاکتیک های معماری باید به دلایل زیر مدل شوند:
امکان ارزیابی مدل ها و بررسی برآورده شدن نیازها
مستند سازی تاکتیک های مورد استفاده، به گونه ای که امکان درک تاکتیک های استفاده شده به سادگی فراهم باشد.
امکان استفاده از مدل ها برای شبیه سازی اجرای برنامه
امکان تبدیل تاکتیک های ایجاد شده به محصولات نرم افزاری مراحل طراحی و پیاده سازی
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

8. هدف از ارائه تز
ارائه روشی برای مدل سازی تاکتیک های کنترل دسترسی و مدیریت اعتماد به گونه ای که :
زبان مدل سازی یک زبان استاندارد باشد.
مدل های ایجاد شده قابل ارزیابی باشند.
تعدادی الگو برای تسهیل امر مدل سازی و مسائل معمول در زمینه کنترل دسترسی و مدیریت اعتماد ارائه شود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

9. مقدمه ای بر امنیت
امنيت، خصوصيتي از سيستم کامپيوتري مي­باشد که از افشاء، تغيير و ممانعت سرويسِ منابع و اطلاعات سيستم به طور غير مجاز جلوگيري کند[Bishop2003] .
سه مفهوم کلي در رابطه با امنيت عبارتند از: محرمانگي، يکپارچگي، صحت و در دسترس بودن سرويس منابع و اطلاعات
حل مسائل امنیتی در سه سطح قابل انجام است[Samarati01] :
خط مشی امنیتی
مدل امنیتی
مکانیزم امنیتی
در این تز هدف حل مسئله امنیت در سطح مدل امنیتی است.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

10. مدل های امنیت مدل کنترل دسترسی مدل مدیریت اعتماد مدل جریان اطلاعات
DAC (Discretionary Access Control)
MAC (Mandatory Access Control )
RBAC (Role Based Access Control )
مدل مدیریت اعتماد
مدل جریان اطلاعات
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

11. مدل RBAC
ویژگی اصلی RBAC توانایی نگاشت ساختار سازمانی طبیعی یک سازمان در مسئله کنترل دسترسی می باشد.
دو مشکل اصلی مدل های کلاسیک را بر طرف نموده است:
کاربر هویت واحد دارد، اما می تواند نقش های گوناگونی را بپذیرد.
مدیریت کنترل دسترسی بسیار آسان می باشد.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

12. مدل مدیریت اعتماد
امروزه اغلب سیستم های نرم افزار در محیط های توزیع شده فعالیت می کنند.
در این گونه سیستم ها وقتی درخواست کننده و منبع در دو حوزه امنیتی مختلف باشند، مسئله کنترل دسترسی با مشکلات زیادی همراه خواهد بود.
هویت درخواست کننده برای منبع روشن نیست.
در این گونه مسائل باید از مدل مدیریت اعتماد استفاده نمود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

13. مدل مدیریت اعتماد
یک مدل مدیریت اعتماد، چارچوبی برای توصیف خط مشی های امنیتی در سیستم های توزیع شده، با توانایی توصیف روابط اعتماد بین اجزای سیستم می باشد [Blaze96] .
از سیستم های مدیریت اعتماد مطرح، می توان به Policy Maker ، KeyNote و SD3 اشاره کرد.
یکی از انواع مدل های مدیریت اعتماد، مدیریت اعتماد مبتنی بر نقش بوده که با گسترش مفاهیم کنترل دسترسی مبتنی بر نقش، نیازمندی های مدیریت اعتماد را برآورده کرده است.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

14. کنترل دسترسی، نقش های سلسله مراتبی و مدیریت اعتماد
برای مشخص شدن کاربرد و تفاوت مدیریت اعتماد با کنترل دسترسی مبتنی بر نقش، و استفاده از نقش های سلسله مراتبی به مثال زیر اشاره می کنیم. این مثال در بخش های دیگر نیز استفاده خواهد شد :
سازمان ACM قصد دارد به دانشجویان دانشگاه امیرکبیر دسترسی به مقالات را ارائه دهد. برای این منظور سه رویکرد کلی وجود دارد :
کنترل دسترسی : پرکردن فرم عضویت توسط دانشجو، تایید آن توسط امیرکبیر و ارسال آن برای ACM. سپس ACM کد کاربری و کلمه عبور برای دانشجوی مذکور ارسال می کند.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

15. کنترل دسترسی، نقش های سلسله مراتبی و مدیریت اعتماد
کنترل دسترسی به کمک نقش های لایه ای : مانند روش قبل می باشد. با این تفاوت که نقشی به نام دانشگاه امیرکبیر در ACM ایجاد شده و دانشجویان زیر مجموعه آن قرار میگیرند. سپس به نقش دانشگاه امیرکبیر دسترسی به مقالات داده می شود و در نتیجه آن تمام زیر مجموعه های امیرکبیر نیز دسترسی پیدا می کنند.
مدیریت اعتماد : دانشجویان در سایت دانشگاه امیرکبیر، و با شناسه کاربری و کلمه عبور دانشگاه خود وارد شوند. سپس با ورود به سایت ACM ، با توجه به اینکه سایت تشخص می دهد درخواست مقالات از سوی یک کاربر مورد تایید از دانشگاه امیرکبیر ارسال شده است، دسترسی به مقالات را به کاربر مذکور ارائه می دهد.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

16. جایگاه کار ارائه شده در امنیت
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

17. مقدمه ای بر معماری نرم افزار
معماري نرم افزار يك برنامه يا سيستم كامپيوتري، ساختار يا ساختارهايي از سيستم مي باشد، كه در برگيرنده اجزاء، صفات قابل مشاهده آن اجزا و ارتباط بين آنها باشد.[Bass03]
اجزاء نرم افزار را تعریف می کند.
شامل ساختارهای مختلف می باشد.
هر سیستم نرم افزار حتماً دارای معماری است.
معماری باید قابل ارزیابی باشد.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

18. طراحی معماری نرم افزار و ویژگی های کیفی
ویژگی های کیفی نیازهای غیر کارکردی هستند.
برای توصیف آنها از سناریوهای ویژگی کیفی استفاده می شود.
برای برآوردن آنها از تاکتیک های معماری و الگوهای معماری استفاده می شود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

19. تاکتیک های معماری (Architectural Tactics)
برای دستیابی به ویژگی کیفی، باید تصمیماتی مربوط به نحوه طراحی معماری اتخاذ نمود. به این تصمیمات پایه تاکتیک معماری نامیده می­شوند.
تاکتیک یک تصمیم طراحی است که با اعمال آن بر روی معماری، می­توان پاسخ ویژگی کیفی را کنترل نمود و آن را به میزان مورد نظر تبدیل نمود [Bass03].
مرجع : [Bass03]
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

20. الگو های معماری (Architectural Patterns)
در معماری نرم افزار الگوهاي معماري یا سبک های معماری شامل شرحي از اجزاء و نوع روابط بين آنها مي باشد به نحوي كه تعدادي قانون براي معرفي اجزاء و نحوه ارتباط بين آنها، مشخص گردد. [Bass 03]
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

21. جایگاه کار ارائه شده در معماری نرم افزار
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

22. کارهای انجام شده
امنیت در مهندسی نرم افزار یک نیاز غیر کارکردی محسوب می شود. [Jürjens04, Doshi01,Chung95, Paech02 ]
نیازهای امنیتی به طور ذاتی به سختي شناسايي، ارزيابي و در سيستم پياده­سازي مي شوند[Jurjens03].
برای جلوگیری از موارد فوق، و با توجه به اینکه امنیت یکی از ویژگی های کیفی سیستم است، باید در تمام چرخه حیات سیستم، مورد توجه قرار گیرد.
بنابراین نیاز به مهندسی نرم افزار سیستم های امن وجود دارد.
فعالیت های همیشگی در مهندسی نرم افزار سیستم های امن
ابزارهای مهندسی نرم افزار سیستم های امن
مدیریت
پیکربندی
تضمین
کیفیت
روش های مهندسی نرم افزار سیستم های امن
معماری
مهندسی نیازها
اندازه
گیری
مدیریت
ریسک
پیاده سازی
تحلیل
تست
طراحی
مدل سازی کسب و کار
فرایند های توسعه سیستم های امن
کیفیت در سیستم های امن
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

23. فرایندهای توسعه سیستم های امن
مدل فرایند پایه
متدولوژی
زبان مدل سازی
مراحل پوشش دهنده
RUPSec
RUP
( تکراری)
شیء گرا
UML
مدل سازی کسب و کار و نیازها
SecureTropos
Tropos
مبتنی بر عامل i*
مدل سازی کسب و کار، نیازها، معماری
[Breu03]
تکراری
UMLSec
نیازها، تحلیل و طراحی
[Kosta2] XP
Agile --
مهندسی نیازها
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

24. روش های مدل سازی کنترل دسترسی و مدیریت اعتماد
متدولوژی
زبان مدل سازی
مرحله مدل سازی
توانایی مدل سازی خط مشی
توانایی مدل سازی کنترل دسترسی
توانایی مدل سازی مدیریت اعتماد
توانایی مدل سازی محدودیت ها
قابلیت ارزیابی مدل ها
قابلیت تبدیل مدل ها به کد
[Koch02]
شیء گرا
UML
طراحی
بله
خیر
[Ahn01]
[Ray04]
UML Diagram Template
طراحی/ پیاده سازی
به صورت غیرخودکار
[Xin06]
MDA
طراحی/پیاده سازی
[Alam07]
UML 2.0
[Salehi07]
معماری
[Ren06]
ساختیافته / شیء گرا
Secure xADL و XACML
برخی ویژگی های مدیریت اعتماد
[Giorgini06]
مبتنی بر عامل i*
مدل سازی سازمان، نیازها و معماری
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

25. روش جدید ارائه شده
با توجه به مقایسه انجام شده، هدف از این تز، ارائه یک روش مدل سازی جدید با ویژگی های زیر است:
متدولوژی: شیء گرا
زبان مدل سازی: UML
مرحله مدل سازی: معماری نرم افزار
با توانایی مدل سازی خط مشی، فرایند کنترل دسترسی و مدیریت اعتماد
امکان ارزیابی مدل ها از دیدگاه امنیتی
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

26. رویکرد کلی به مسئله ایجاد زبان مدل سازی
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

27. نیازمندی های مسئله مدل سازی مدیریت اعتماد
1 - ويژگي‌هاي توزيع شده : يك موجوديت مي‌تواند ادعا كند كه موجوديت ديگري داراي تعدادي ويژگي خاص است.
2 - انتقال قدرت تصميم گيري در مورد يك ويژگي : يك موجوديت قدرت تصميم گيري در مورد يك ويژگي را به يك موجوديت ديگر انتقال مي‌دهد ( به بيان ديگر يك موجوديت به تصميم موجوديت ديگر در مورد يك ويژگي، اعتماد مي‌كند.)
3 - استنتاج ويژگي‌ها : يك موجوديت از يك ويژگي براي انجام استنتاج در مورد ويژگي‌هاي ديگر آن موجوديت استفاده مي‌كند.
4 – امکان ترکیب ویژگی ها : گاهي لازم است در تصمیمات مربوط به کنترل دسترسی، چندین ویژگی با هم ترکیب شوند. به این معنا که در صورتی که یک عنصر دارای تمام ویژگی های مورد نظر بود، دسترسی به وی داده شود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

28. چارچوب RT
چارچوبی است که توانایی برآورده نمودن نیازمندی های اشاره شده را دارد.
چارچوبي براي توصيف سياست‌ها و مجوز‌ها براي مديريت اعتماد در سيستم‌هاي توزيع شده می باشد.
بر مبنای روش RBAC بنا شده و در حقیقت گسترشی بر روش RBAC محسوب می شود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

29. عناصر پایه تشکیل دهنده چارچوب RT
موجودیت ها
درخواست انجام عمل
صدور مجوز
نام نقش
نقش
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

30. روابط RT برای توصیف خط مشی ها
عضویت یک عنصر در یک نقش :
اعطای یک نقش به نقش دیگر :
نقش های ترکیبی :
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

31. روش های گسترش UML
قیود (Constraints) : برای محدود کردن مدل ها و با زبان OCL نوشته می شوند.
مقادیر برچسبی (Tagged Value) : برای اضافه شدن برخی ویژگی ها به اجزاء مدل سازی به کار می روند.
کلیشه ها (Stereotypes) : که برای نام گذاری مجموعه ای از قیود و مقادیر برچسبی به کار می روند. نام مذکور در بین علامت << >> قرار گرفته و مشخص می کند که عنصر مدل سازی جدیدی با این نام و دارای تعدادی قید و مقادیر برچسبی ایجاد شده و می توان از آن در ساخت مدل ها استفاده نمود.
پروفایل (Profile) : که مجموعه ای از قیود، مقادیر برچسبی و کلیشه ها بوده و برای مدل سازی سیستم ها در یک حوزه خاص به کار می رود.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

32. معماری UML و سطوحی که می توان در آنها گسترش ایجاد نمود.
Meta-Meta Model
استفاده از زبان UML به صورت موجود
گسترش UML با استفاده از محدود کردن عناصر مدل سازی
گسترش متامدل UML
روش
راحتی یادگیری
ابزار
خوانایی مدل­ها
پوشش مفاهیم مدیریت اعتماد
استاندارد بودن
UML موجود
زیاد کم
استاندارد است.
UML محدود
متوسط
گسترش متامدل
موجود نیست.
استاندارد نیست.
Meta Model
Model
User Objects
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

33. مدل سازی موجودیت ها
برای مدل سازی موجودیت های سیستم ، کلاس UML را با کلیشه <<SecureComponent>> مدل می کنیم.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

34. مدل سازی نقش
[1] -- isMember Operation for SecureRole Meta-class
[2] Context SecureRole
[3] def : isMember(component: SecureComponent) : Boolean
[4] body :
[5] let delegationAssc = self.associationEnd.association-> Select(delegations| streotype=Delegation)
[6] let delegatedRoles = delegationAssc.associationEnd.class-> Select(classes | classes<>self)
[7] let componentHasAttributes = component.associationEnd.association-> Select(attributeOwn| streotype=HasAttribute)
[8] let componentAttributes = componentHasAttributes.associationEnd.class->Select(classes | streotype=SecureAttribute)
[9] componentAttributes->exists((name = RoleName) or delegatedRoles-> exist(isMember(component)))
بیانگر یک ویژگی در سیستم که دسترسی بر اساس آن اعطا می شود.
باید دارای یک تابع تصمیم گیری در مورد عضویت یا عدم عضویت یک جزء در نقش مربوطه باشد. برای عضویت:
جزء دارای ویژگی نقش مربوطه باشد.
جزء مورد نظردارای یک ویژگی است که نقش مربوطه در یک یا چند سطح به آن اعطا شده است.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

35. رابطه اعطا کردن رابطه اعطا کردن بین دو نقش رخ می دهد.
عنصری اعطا شونده به عنوان وکیل عنصر اعطا کننده عمل خواهد کرد.
با توجه به اینکه بیان کننده رابطه بین دو کلاس است، عنصر Association در UML را به کمک کلیشه <<Delegation>> گسترش می دهیم.
[1] -- Constraint on association ends for delegation relationship
[2] inv:
[3] self.associationEnd->forAll(end| end.Streotype="SecureRole")
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

36. رابطه داشتن ویژگی
این رابطه مشخص کننده عضویت یک جزء در یک نقش است. به بیان دیگر می توان گفت که جزء دارای نقش مربوطه است.
رابطه بین یک SecureRole و SecureComponent رخ می دهد.
بهترین عنصر UML برای نمایش رابطه داشتن ویژگی، عنصر Association بوده که آن را با کلیشه <<HasAttribute>> گسترش می دهیم.
[1] -- Constraint on association ends for HasAttribute relationship
[2] inv:
[3] self.associationEnd->Size = 2
[4] let ends = self.associationEnd in
[5] (ends[1].class.streotype = SecureComponent and ends[2].class.streotype = HasAttribute) or (ends[2].class.streotype = SecureComponent and ends[1].class.streotype = HasAttribute
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

37. مدل سازی رابطه عضویت این رابطه بین یک جزء و یک نقش ایجاد می شود.
این رابطه یک رابطه محدود است و تنها در صورتی امکان ایجاد آن وجود دارد که جزء مورد نظر به طور مستقیم یا غیر مستقیم عضوی از نقش مربوطه باشد.
برای نمایش آن عنصر Association در UML را به کمک کلیشه <<isMember>> گسترش می دهیم.
[1] -- Constraint On Membership of Requester Component in Secure Role
[2] let SecureRoleClass = self.associationEnd->Select(end | end.Streotype=SecureRole) in
[3] let RequesterComponent = self.associationEnd->Select(end | end.Streotype=Component) in
[4] SecureRoleClass.isMember(RequesterComponent)
[5] -- Constraint on association ends for IsMember relationship
[6] inv:
[7] self.associationEnd->Size = 2
[8] let ends = self.associationEnd in
[9] ends[1].class.streotype = SecureComponent and ends[2].class.streotype = HasAttribute
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

38. مدل سازی رابطه مالکیت یک نقش
هرگاه یک نقش، توسط یک جزء ارائه شود، می گوییم جزء مربوطه مالک نقش است.
بین یک جزء و نقش رخ داده و آن را با گسترش Association در UML به وسیله کلیشه <<OwnRole>> مدل می کنیم.
دارای دو محدودیت است:
بین یک SecureRole و SecureComponent رخ می دهد.
هر نقش تنها می تواند یک مالک داشته باشد.
[1] -- Constraint on having just one Owner
[2] inv:
[3] let role = self.associationEnd[1].class in
[4] role.associationEnd.Association->forAll( e | (e.Streotype=OwnRole) implies (e = self)
[5] -- Constraint on association ends for OwnRole relationship
[6] inv:
[7] self.associationEnd->Size = 2
[8] let ends = self.associationEnd in
[9] ends[1].class.streotype = SecureComponent and ends[2].class.streotype = SecureRole
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

39. مدل سازی واسط ها (Interface)
هر جزء برای ارائه سرویس به دیگر اجزاء دارای تعدادی واسط است.
واسط ها باید از دسترسی افراد غیر مجاز محافظت شوند. برای این منظور از مفهومی به نام محافظ (Safeguard) در آنها استفاده می شود.
برای نمایش واسط ها، از عنصر Interface در UML استفاده می کنیم و آن را با کلیشه <<SecureInterface>> گسترش می دهیم.
هر SecureInterface یک واسط است که توسط تعدادی نقش محافظت می شود. هر جزء دیگر برای دسترسی به آن باید دارای همه نقش های محافظ باشد.
نقش های لازم برای دسترسی به واسط مربوطه توسط یک Tag در UML به آن متصل می شود.
[1] – Safeguards Tag is added to the extended interface. It contains the list of safeguards required to access the interface.
[2] Safeguards : Set of String
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

40. تابع تصمیم گیری در مورد کنترل دسترسی
[1] -- Access Control Function for the meta class Model
[2] Context Model
[3] def : HaveAccess(component: SecureComponent, interface: SecureInterface) : Boolean
[4] let componentRoles = interface.class.associationEnd.association.associationEnd->Select(RoleEnds | RoleEnds.association.Streotype=OwnRole and RoleEnds.class.Streotype = SecureRole) in
[5] let safeguardRoles = componentRoles->Select( roles | interface.Safeguards.Contains(roles.Name) ) in
[6] = safeguardRoles->forAll(safeguardRole | safeguardRole.isMember(component)
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

41. الگوهای معماری برای مدل سازی مدیریت اعتماد (عضویت یک جزء در یک نقش)
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

42. الگوی معماری اعطا کردن یک نقش به نقش دیگر
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

43. الگوی نقش های سلسله مراتبی
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

44. الگوی معماری اعطاکردن چندگانه
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

45. مثال نمونه
مسئله : سازمان ACM قصد ارائه دسترسی به مقالات به دانشجویان دانشگاه امیرکبیر دارد.
راه حل :
ارائه دسترسی به مقالات به تک تک دانشجویان دانشگاه امیرکبیر با ارائه کد کاربری و کلمه عبور (کنترل دسترسی)
ارائه دسترسی به دانشگاه امیرکبیر و ارائه کد کاربری و کلمه عبور به تک تک دانشجویان و قرار دادن آنها در زیرمجموعه امیرکبیر (کنترل دسترسی با استفاده از نقش های لایه ای)
ارائه دسترسی به مقالات به تمام درخواست هایی که از طرف افراد مورد تایید امیرکبیر آمده است (مدیریت اعتماد).
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

46. مدل سازی راه حل اول
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

47. مدل سازی راه حل دوم
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

48. مدل سازی راه حل سوم
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

49. کارهایی که باید انجام شوند
ارائه یک مطالعه موردی برای تست تمام ویژگی های زبان مدل سازی گسترش یافته.
ارائه پارامترهای ارزیابی مناسب برای زبان مدل سازی گسترش یافته و مقایسه آن را زبان های موجود برای مدل سازی مدل سازی کنترل دسترسی و مدیریت اعتماد.
ارائه کاربردهای زبان مدل سازی در ارزیابی معماری نرم افزار.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML

50. خلاصه گسترش های ارائه شده
کلیشه
کلاس پایه
برچسب
محدودیت
شرح
SecureComponent
Class --
یک جزء در سیستم که توانایی ارائه درخواست و مالکیت نقش ها را دارد.
SecureRole
تابع عضویت
یک نقش در سیستم که دسترسی بر مبنای آن تعیین می شود.
Delegation
Association
برقرار رابطه تنها بین کلاس هایی از نوع SecureRole
رابطه مشخص کننده اعطای یک نقش به نقش دیگر
HasAttribute
رابطه از نوع Binary و بین یک SecureComponent و یک Secure Role
مشخص کننده دارا بودن یک نقش توسط یک جزء
OwnRole
Associaation
بین یک SecureComponent و Secure Role و هر نقش تنها می تواند یک مالک داشته باشد.
مشخص کننده مالکیت یک نقش توسط یک جزء
IsMember
بین یک SecureComponent و Secure Role ایجاد شده و تنها در صورتی وجود دارد که جزء عضوی از نقش باشد.
رابطه ای محدود که تنها اگر جزء مربوطه عضو یک نقش باشد امکان برقراری آن وجود دارد.
SecureInterface
Interface
Safeguards
واسط امن که توسط تعداد محافظ محافظت می شود.
برچسب
کلیشه
نوع
تعداد
شرح
Safeguards
SecureInterface
String *
شامل نام تمام نقش هایی که یک جزء باید برای دسترسی به واسط مورد نظر دارا باشد.
آزمايشکاه سيستم های هوشمند (
مدل سازی کنترل دسترسی و مديريت اعتماد با UML