مدل مديريتي كنترل دسترسي نقش مبنا امنيت پايگاه داده ، ارديبهشت 1386 صالح حافظ قرآني دانشگاه صنعتی شريف , دانشکده مهندسی کامپيوتر
فهرست مطالب امنيت پايگاه داده مدل كنترل دسترسي نقش - مبنا مديريت در كنترل دسترسي نقش- مبنا مدل مديريت در كنترل دسترسي نقش- مبنا پياده سازي مدل PRA97 براي انتساب مجوز به نقش در Oracle كنترل دسترسي نقش- مبنا و MAC استفاده از RBAC براي اعمال DAC و MAC جمع بندي مراجع
امنيت پايگاه داده جنبه هاي مهم در برقراري امنيت كنترل دسترسي كاربران به داده ها بايستي مدلي ارائه شود تا تعيين گردد كه چه دسترسي‌هايي مجاز و چه دسترسي‌هايي غير مجاز است. پايگاههاي داده با توجه به متمركزسازي داده ها در آن بيشتر مورد توجه قرار می‌گيرند. مدل كنترل دسترسي نقش- مبنا به عنوان يك مدل كنترل دسترسي بسيار مرسوم و پركاربرد مطرح است. ...
مدل كنترل دسترسي نقش - مبنا کنترل دسترسي اجباري يا MAC کنترل دسترسي اختياري يا DAC کنترل دسترسي نقش- مبنا يا RBAC علت كاربرد زياد اين مدل براي كنترل دسترسي ها ( مزايا ) : سادگي مديريت آن . نگاه واقعي مدل به محيط هاي عملياتي. مجوز دسترسي بر اساس نقش ها در سازمانهاست نه بر اساس مالكيت داده‌ها. مدل RBAC به خوبي سياست امنيتي پيچيده را مديريت ميکند.
طرح يك مشكل و ارائه يك راه‌حل اگر سيستمي با هزاران كاربر و صدها نقش و مجوز در نظر بگيريم، مديريت نقشها و انتساب كاربران به نقشها و مجوزها به نقشها و همچنين ساخت سلسله مراتب از نقشها بسيار پيچيده و مشكل مي‌گردد و نمي‌توان آن را توسط يك مدير در سيستم انجام داد. راهكار : مديريت غير متمركز. در نظر كرفتن نقشهاي مديريتي و حوزه‌هاي مديريتي براي هر نقش همچنين ايجاد سلسله مراتبي از آنها واگذاري مديريت به افراد مختلف در حوزه‌هاي گوناگون سيستم هر مدير مسؤوليت مديريت در حوزه خود را بر عهده داشته باشد
خانواده مدل هاي RBAC RBAC0 به عنوان مدل پايه در پايين داراي کمترين نيازمنديهاي سيستم RBAC مي باشد. RBAC1 سلسله مراتبي از نقشها را به آن اضافه کرده است به طوريکه نقشها مي توانند از نقشهاي ديگر به ارث ببرند RBAC2 قيودي را تعريف ميکند که محدوديت‌هايي را به تنظيمات قابل قبول براي مولفه ها در RBAC اضافه مي‌نمايد. مدل Consolidated ، شامل هر دو RBAC1 و RBAC2 و به صورت ضمني، RBAC0 نيز مي باشد.
RBAC0 يا مدل پايه چهار مولفه : کاربران : نقش ها اختيارات يا مجوزها چهار مولفه : کاربران : منظور از کاربر، انسان مي باشد. فردی که با سيستم تعامل دارد. نقش ها نقش، يک کار نامدار درون سازمان است که سازمان مجوز ها و مسئوليت ها را به اعضاي يک نقش مي دهد. اختيارات يا مجوزها به کسي که دارنده اختيار است، قدرت انجام يک عمل در سيستم را مي دهد. نشست ها کاربر با فعال کردن يک مجموعه از نقش ها که به او متعلق است، نشست ها را برقرار ميکند.
RBAC1 يا مدل سلسله مراتب سلسله‌مراتب به معني ساختار نقش‌ها‌ست که حدود مجوزها و مسئوليت‌ها در سازمان را باز‌مي‌تاباند. اين سلسله‌مراتب يک مجموعه ترتيب جزئي است. يک ترتيب جزئي، خواص بازتابي، انتقالي و پاد تقارني را داراست.
سلسله مراتب محدود کردن وراثت زير سلسله مراتب خصوصي ممکن است بخواهيد تعدادي اختيارات محرمانه براي خود داشته باشد و از به ارث رسيدن آنها به ساير نقشها جلوگيري کنيد. زير سلسله مراتب خصوصي فرض کنيد که به زير مجموعه محرمانه‌اي نياز باشد به طوريکه اختيارات آنها توسط بالايي‌ها به ارث برده نشود.
RBAC2 يا مدل قيود قيود جنبه مهمي از RBAC هستند. يک مثال رايج جدا کردن نقش هاي سازمان است. نقش هاي انحصار متقابل : يک کاربر مي تواند به حداکثر يک نقش در مجموعه انحصار متقابل نسبت داده شود. که اين قيود باعث جدا کردن وظايف از يکديگر مي شود. انحصار متقابل در مورد PA ، مشخص مي کند که يک اختيار خاص نتواند به دو نقش نسبت داده شود. دانه بندي : يک قيد ديگر روي کاربر است . حداکثر تعداد اعضاي يک نقش می تواند محدود باشد. تنها يک نفر مي تواند رئيس يک سازمان باشد. تعداد نقش هاي يک کاربر مي تواند به مجموعه خاصي محدود شود و يا به تعداد خاصي محدود گردد.
RBAC2 يا مدل قيود ( ادامه ) نقشهاي پيش شرط : ايده آن مبتني بر شايستگي‌ها است، به طوريکه کاربر مي تواند به نقش A نسبت داده شود و اگر تنها اگر کاربر قبلا به نقش B نسبت داده شده باشد. براي سازگاري، اختيار p ، مي تواند به يک نقش تنها در صورتيکه نقش در حال حاضر داراي اختيار q است، نسبت داده شود. در بسياري از سيستم ها اختيار خواندن يک فايل مستلزم داشتن اختيار خواندن از دايرکتوري مي باشد.
RBAC3 يا مدل Consolidated 3 = 1 + 2 تلفيق اين دو، موارد قابل بحث جديدي را بوجود مي آورد : قيود روي سلسله مراتبي از نقشها : چون قيود و سلسله مراتب هر دو در مدل ديده مي شوند ، قيود را روي سلسله مراتب هم مي‌توان تعريف كرد. قيود ميتوانند تعداد نقشهاي بالاتر و پايين تر را محدود کند. تقابلات : تقابل ظريفي بين قيود و سلسله مراتب بوجود مي آيد. نقش هاي محرمانه : نقش هاي محرمانه مي توانند بدون هيچ برخورد و تلاقي، انحصار متقابل باشند.
اجزاء مدل کنترل دسترسی نقش‌مبنا المان‌هاي مدل RBAC کاربران U نقشها R مجوزها P جلسه‌ها S محدوديتها C سلسله مراتب نقشها RH RBAC3 RH سلسله مراتب نقشها RBAC1 UA انتساب کاربر به نقش U کاربران R نقشها P مجوزها PA انتساب مجوز به نقش User S جلسات Roles RBAC2 محدوديتها
مديريت در كنترل دسترسي نقش- مبنا در سيستم بزرگ که تعداد نقشها به صدها و هزاران افزايش مي‌يابد، مديريت اين نقش ها و روابط ميان آنها يک کار سخت که به صورت مرکزي انجام ميشود و به گروه کوچکي از مديران امنيتي محول مي‌گردد. از آنجا که نکته اصلي RBAC اين است که مديريت را ساده ميکند، مي‌توان از خود آن در مديريت خودش استفاده نمود. نقشهاي مدير يا AR و اختيارات مدير يا AP را از نقش هاي معمولي يا R و اختيارات معمولي يا P جدا مي‌كنيم . اختيارات تنها به نقش ها نسبت داده مي‌شوند و اختيارات مديريتي تنها به نقشهاي مديريتي نسبت داده مي‌شوند.
مديريت در سيستم هاي نقش- مبنا پروژه تحقيقاتي European Union : پروژه Webocracy و سيستم Web-Based مربوطه اهداف : فراهم آوردن سرويس هاي دولتي Quality Of Service … ماجول CSAP Communication, Security, Authentication, Privacy ماجول CAC به عنوان ابزار مديريت ماجول فوق CSAP Administration Console
مدل مديريتي RBAC انواع مدل هاي بحث شده، براي مدير نيز مطرح است. البته معمولا مدل مدير ساده تر از خود مدل RBAC است. بنابراين مي توان از RBAC0 به جاي RBAC3 استفاده نمود. چگونه مدل سلسله مراتبي مدل مدير مديريت مي شود؟ به طور تئوريک، سطح دوم از سلسله مراتب مي تواند براي مديريت سطح اول مورد استفاده قرار گيرد. ولي براي مدل ضروري نمي باشد. مديريت سلسله مراتب مدير ميتواند توسط يک نفر رئيس سيستم مديريت انجام شود. مجوزهاي مدير در RBAC توانايي تغيير نسبت دادن نقش به کاربران و نيز تغيير دادن نسبت دادن اختيارات به نقش ها و روابط موجود در سلسله مراتب نقش ها را به وجود آورد.
انتساب مجوزهاي مديريتي به نقش اجزاء مدل مديريتي RBAC S جلسات APA انتساب مجوزهاي مديريتي به نقش U کاربران AR نقشهاي مديريتي AP مجوزهاي P مجوزها R نقشها محدوديتها AUA انتساب کاربر به نقش UA ARH سلسله مراتب نقشهاي مديريتي RH PA انتساب مجوز به نقش Roles User
اجزاء مدل مديريتي RBAC اين مدل در سال 1997 توسط Sandhu ارائه گرديد. ايده اصلي آن استفاده از خود مدل RBAC براي مديريت آن بود. اين مدل شامل سه مدل اصلي به شرح زير مي باشد : مدل URA يا مدل انتساب كاربران به نقش مدل PRA يا مدل انتساب مجوزها به نقش مدل PRA يا مدل انتساب نقش به نقش
مدل URA يا مدل انتساب كاربران به نقش اين مدل داراي 2 مؤلفه اصلي است : انتساب كاربران به نقش ها يا مدل Gant Can-assign باز پس گيري عضويت آنها در نقش ها يا Revoke Can-revoke رابطه Can-assign بيان مي‌كند كه چه افرادي با چه پيش‌شرط‌هايي ميتوانند در چه حوزه‌اي كار اعطاء را انجام دهند. افراد را با نقشهاي مديريتي كه دارا هستند معين مي كند. يعني نقشي را بيان مي كند كه افراد براي اعمال كارهاي مديريتي در يك حوزه خاص بايد دارا باشند. رابطه Can-revoke بيان مي‌كند كه چه افرادي در چه حوزه‌هايي ميتوانند عمل بازپس‌گيري را انجام دهند. اين توابع براي عمل انتساب و بازپس‌گيري نقش ها به كاربران به كار مي‌رود و بايستي در هر عمل، امكان انجام آنرا توسط آنها چك كرد.
مدل URA97 تابع Can_assign داراي سه پارامتر ورودي است X كه نقش مديريتي فردي كه مي خواهد عمل انتساب را انجام دهد را مشخص مي كند. Y نقش پيش شرط فردي است كه مي خواهيم به او نقش را انتساب دهيم و Z كه دامنه نقش هاي قابل انتساب را معين مي كند. يعني فرد داراي نقش مديريتي X به يك كاربر كه فعلا داراي نقش Y است مي تواند هر نقشي در دامنه Z عطا كند.
مدل URA97 - رابطه Can_Assign اولين سطر اين جدول بيان ميکند که کاربري با نقش "کارشناس امنيتي سيستم صورتحساب‌‌گيري" (BCS) و در نتيجه "کارشناس امنيتي امور رايانه" (CS) و "مديرکل امنيتي" (SSO) ميتواند به کاربري که هم‌‌اکنون داراي نقش عادي "واحد رايانه" (CD) است, نقش "کارشناس سيستم صورتحساب گيري" (BC) را عطا کند. دامنه نقشها پيش‌شرط نقش مديريتي [BC,BC] CD BCS [PO,] BC ^ ¬BO [BO,BO] BC ^ ¬PO [CC,CC] CCS [RO,RO] CC ^ ¬CO [CO,CO] CC ^ ¬RO [BCM,BCM] CD ^ ¬CCM CS [CCM,CCM] CD ^ ¬BCM (CD,CDM) [CD,CD] E SSO (CD,CDM] کارشناس امورمتقاضيان (RO) کارشناس صورتحسابها (BO) رئيس سيستم صورتحساب گيري (BCM) کارمند(E) واحد رايانه (CD) کارشناس سيستم متقاضيان - مشترکين (CC) کارشناس سيستم صورتحساب گيري(BC) رئيس سيستم متقاضيان –مشترکين (CCM) مدير عامل اداره رايانه (CDM) کارشناس وصوليها(PO) کارشناس امور مشترکين (CO) کارشناس امنيتي امور رايانه (CS) کارشناس امنيتي سيستم متقاضيان - مشترکين (CCS) کارشناس امنيتي سيستم صورتحساب گيري (BCS) مدير کل امنيتي (SSO)
مدل URA97 تابع Can_Revoke داراي دو پارامتر ورودي است. X كه نقش مديريتي فردي كه مي خواهد عمل بازپس گيري نقش را انجام دهد را مشخص مي كند. Z دامنه نقش هايي را كه مي تواند بازپس گيرد تعيين مي كند . هيچ پيش شرطي براي اين تابع تعريف نمي گردد.
مدل URA97 - رابطه Can_Revoke سطر دوم اين جدول بيان ميکند که "کارشناس امنيتي بخش متقاضيان و مشترکين" ميتواند از تمام کاربران سيستم, نقش "کارشناس سيستم متقاضيان و مشترکين" (CC) , "کارشناس امور متقاضيان" (RO) و "کارشناس امور مشترکين" (CO) را بازپس‌گيرد. دامنه نقشها نقش مديريتي [BC,BCM) BCS [CC,CCM) CCS (CD,CDM) CS [CD,CDM] SSO کارشناس امورمتقاضيان (RO) کارشناس صورتحسابها (BO) رئيس سيستم صورتحساب گيري (BCM) کارمند(E) واحد رايانه (CD) کارشناس سيستم متقاضيان - مشترکين (CC) کارشناس سيستم صورتحساب گيري(BC) رئيس سيستم متقاضيان –مشترکين (CCM) مدير عامل اداره رايانه (CDM) کارشناس وصوليها(PO) کارشناس امور مشترکين (CO) کارشناس امنيتي امور رايانه (CS) کارشناس امنيتي سيستم متقاضيان - مشترکين (CCS) کارشناس امنيتي سيستم صورتحساب گيري (BCS) مدير کل امنيتي (SSO)
مدل PRA97 يا مدل انتساب مجوزها به نقش اين مدل نيز مشابه مدل قبلي داراي 2 مؤلفه اصلي است : مدل Grant براي اعطاء مجوزها به نقش ها Can- assignp مدل Revoke براي بازپس گيري مجوز از نقش ها Can- revokep رابطه اول وظيفه تعيين افراد و شرط ها براي انجام عمل انتساب در يك حوزه خاص و رابطه دوم وظيفه تعيين افراد براي انجام عمل بازپس گيري در يك حوزه خاص را بر عهده دارد.
مدل PRA97 تابع Can_Assignp داراي سه پارامتر ورودي است . X كه نقش مديريتي مجري عمل انتساب را مشخص مي كند. Y نقش اي است كه مي توان مجوزهاي آن را براي عمل انتساب انتخاب كرد. Z ، حوزه نقش هايي است كه مي توان مجوز انتخاب شده را به آن نسبت داد.
مدل PRA97 - رابطه Can_AssignP سطر اول اين جدول بيان مي‌دارد که کاربري با نقش "کارشناس امنيتي امور رايانه" (CS) يا "مديرکل امنيتي" (SSO) ميتواند تمام مجوزهاي صريح و ضمني نقش "مديرعامل اداره رايانه" (CDM) يعني در واقع تمام مجوزهاي موجود در سيستم را به نقش "رياست سيستم صورتحساب‌‌گيري" (BCM) عطا کند. دامنه نقشها پيش‌شرط نقش مديريتي [BCM,BCM] CDM CS [CCM,CCM] [PO,] BCM ^ ¬BO BCS [BO,BO] BCM ^ ¬PO [RO,RO] CCM ^ ¬CO CCS [CO,CO] CCM ^ ¬RO کارشناس امورمتقاضيان (RO) کارشناس صورتحسابها (BO) رئيس سيستم صورتحساب گيري (BCM) کارمند(E) واحد رايانه (CD) کارشناس سيستم متقاضيان - مشترکين (CC) کارشناس سيستم صورتحساب گيري(BC) رئيس سيستم متقاضيان –مشترکين (CCM) مدير عامل اداره رايانه (CDM) کارشناس وصوليها(PO) کارشناس امور مشترکين (CO) کارشناس امنيتي امور رايانه (CS) کارشناس امنيتي سيستم متقاضيان - مشترکين (CCS) کارشناس امنيتي سيستم صورتحساب گيري (BCS) مدير کل امنيتي (SSO)
مدل PRA97 تابع Can_Revokep داراي دو پارامتر ورودي است كه x نقش مديريتي مجري عمل بازپس گيري و z حوزه نقش هايي است كه مي توان در آن حوزه عمل بازپس گيري مجوز ها را انجام داد. y در PRA حوزه انتخاب مجوزها را در تابع Can_Assignp مشخص مي كند. در حالي كه در URA پيش شرط براي اخذ نقش بود. بنابراين در PRA مي توان y را به عنوان Permission pool يا حوزه اي براي انتخاب مجوز ها جهت انتساب دانست.
مدل PRA97 - رابطه Can_RevokeP سطر اول اين جدول بيان ميکند که "کارشناس امنيتي سيستم صورتحساب‌‌گيري" (BCS) و طبيعتا "کارشناس امنيتي امور رايانه" (CS) و "مديرکل امنيتي" (SSO) ميتوانند هر مجوزي را از "کارشناس صورتحسابها" (BO) و "کارشناس وصوليها" (PO) بازپس‌‌گيرند. دامنه نقشها نقش مديريتي (BC,BCM) BCS (CC,CCM) CCS (CD,CDM) CS [CD,CDM] SSO کارشناس امورمتقاضيان (RO) کارشناس صورتحسابها (BO) رئيس سيستم صورتحساب گيري (BCM) کارمند(E) واحد رايانه (CD) کارشناس سيستم متقاضيان - مشترکين (CC) کارشناس سيستم صورتحساب گيري(BC) رئيس سيستم متقاضيان –مشترکين (CCM) مدير عامل اداره رايانه (CDM) کارشناس وصوليها(PO) کارشناس امور مشترکين (CO) کارشناس امنيتي امور رايانه (CS) کارشناس امنيتي سيستم متقاضيان - مشترکين (CCS) کارشناس امنيتي سيستم صورتحساب گيري (BCS) مدير کل امنيتي (SSO)
مدل RRA يا مدل انتساب نقش به نقش ايجاد يك سلسله مراتب از نقش ها فراهم آوردن بستري براي ساخت مدل RBAC1 وقتي نقشي، بالاتر از يك نقش ديگر قرار مي گيرد، تمام مجوزهاي نقش قبلي را به ارث مي برد. يعني نقش بالاتر تمام مجوزهاي نقش پايين تر را داراست علاوه بر آن يك سري مجوز هاي خاص خود را نيز دارد. اين مدل سلسله مراتبي با توجه به ساختار سلسله مراتبي نقش هاي سازماني مي تواند شكل بگيرد و به هر چه بهتر مدل كردن نقش ها و نقش هاي مديريتي موجود سازمان در سيستم كمك كند.
مشکلات موجود در مدل مديريتي ARBAC97 ضعف‌هاي مدل URA 97 انتساب چندمرحله‌‌اي نقش به کاربر اطلاعات انتسابات نقش به کاربر تکراري محدوديت در مفهوم User Pool ضعف‌هاي مدل PRA97 انتساب چندمرحله‌‌اي مجوز به نقش اطلاعات انتسابات مجوز به نقش تکراري محدوديت در مفهوم Permission Pool عدم امکان تعريف محدوديت در مفهوم Permission Pool اثر جانبی ناخواسته (انتساب به خارج از حوزه مديريتي)
مدل Role Graph از ديد ديگر مدل كنترل دسترسي نقش مبنا را مبتني بر سه گراف در سه حوزه مختلف بررسي مي كنند : گراف اختيارات يا مجوز ها : اين گراف بيانگر سلسله مراتب حاكم برانواع مجوزهاي مختلف است. ممكن است داشتن يك مجوز ، داشتن يك مجوز ديگر را ايجاب كند. گراف گروه ها يا كاربران : در اين گراف كاربران يا گروهاي كاربري و سلسله مراتب آنها نمايش داده مي شود. گراف نقش ها ياRole Graph : در اين گراف نقش هاي موجود سيستم ، گره هاي گراف را تشكيل مي دهند و خط بين آنها ارتباط شامل شدن را معين مي كند.
اجزاء مدل Role Graph
مديريت غيرمتمركز در مدل Role Graph مطابق همين ديد به مدل كنترل دسترسي ، گراف نقش هاي مديريتي نيز قابل ترسيم است. اين گراف شامل نقش هاي عادي و نقش هاي مديريتي است و دو رابطه در آن تعريف مي گردد : رابطه Is-Junior رابطه اي بين نقش هاي عادي و يا بين نقش هاي مديريتي است. اين رابطه نشان دهنده شامل بودن يك نقش بر نقش ديگر است. رابطه دوم، رابطه Administrates است كه با خط هاي خط چين در شكل نشان داده شده است. اين گراف داراي دو گره به نامهاي MinRole و MaxRole و SSO كه وظيفه مديريت كل سيستم را بر عهده دارد ، در نظر گرفته مي شود.
حوزه هاي مديريتي در Role Graph
ساخت گراف نقشهاي مديريتي مطابق شكل a در ابتدا سه نقش و يك حوزه مديريتي كلي با مديريت SSO وجود دارد . مطابق شكل b بخشها به تدريج اضافه مي شوند و گراف بزرگتر مي شود.
مدل مديريتي RBAC توسعه يافته سعي شده است مشكلات مطرح شده، در مدل توسعه يافته يعني ARBAC02 حل گردند. در اين مدل مفاهيم User Pool و Permission Pool مطرح مي شود و سعي مي گردد تا با حل تداخل هاي غيرلازم موجود ، مشكلات مطرح شده كنار گذاشته شود. براي غلبه بر مشكلات مطرح شده در مدل قبل، دو استراتژي در اين مدل اتخاذ شده است: اول، از ساختار سازماني به عنوان User pool و Permission pool استفاده مي شود به جاي اينكه از پيش شرط هايي در سلسله مراتب نقش ها استفاده كرد. دوم، توسط اين ساختار سازماني يك روند پائين به بالا براي انتساب مجوز ها به نقش ها مطرح ميشود.
ساختار سازماني براي توسعه سيستم هاي اطلاعاتي،"سازمان" يك مفهوم خوب براي تحليل فعاليت هاي موجود در هر دامنه است. ساختار سازماني يك ساختار درختي با ويژگي سلسله مراتبي است. اين ساختار از المان هاي سازماني تشكيل مي شود كه افراد متعلق به هر يك داراي يك هدف مشترك در سازمان هستند و يك سري فعاليتهاي خاص براي رسيدن به آنها انجام مي دهند. كارهاي انجام يافته با داده هاي مورد دسترسي ارتباط مستقيم دارد. پس فعاليت ها و كارهاي يك بخش با مجوز هاي آن ارتباط دارد. پس مي توان واحد سازماني را به عنوان يك گروه از كاربران و مجوز ها براي رسيدن به هدف خاص تعريف كرد.
ساخت User & Permission Pool ساختار سازماني Permission pool User pool By Human Resource Group By IT Management Group حال مدير هاي امنيتي، كاربران و مجوزهاي موجود در هر واحد سازماني را به نقش ها نسبت مي دهند.
ساختار مدل مديريتي RBAC توسعه يافته
اصلاح مدل با اعمال مفهوم ساختار سازماني توابع Can_Assign و Can_Assignp همان توصيف موجود در ARBAC97 را دارا هستند و فقط پيش شرط ها در آن مجددا تعريف شده است : پيش شرط ها در URA يك عبارت با تركيب عملگرهاي And و Or روي نقش هاي عادي و يا واحد هاي سازماني در ساختار سازماني تهيه شده توسط گروه HR يعني User Pool است. پيش شرط ها در PRA يك عبارت منطقي از عملگر هاي And و Or روي عبارات x و ~x است كه x يك نقش عادي يا يك داحد سازماني ذر ساختار سازماني تهيه شده توسط گروه IT يا Permission Pool است.
انتساب مجوزهاي مديريتي به نقش اجزاء مدل ARBAC02 ساخت Permission Pool با يک ساختار سازماني به نام OS-P ساخت User Pool با يک ساختار سازماني به نام OS-U S جلسات APA انتساب مجوزهاي مديريتي به نقش U کاربران AR نقشهاي مديريتي R نقشها محدوديتها AUA انتساب کاربر به نقش UA ARH سلسله مراتب نقشهاي مديريتي RH PA انتساب مجوز به نقش Roles User User Pool OS-U Permission Pool OS-P AP مجوزهاي P مجوزها
كنترل دسترسي نقش- مبنا و MAC Role Graph Model يال در گراف نقش و رابطه Is Junior الگوريتم ساخت گراف خصوصيات گراف نقش تعريف يك سري شرايط محدوديت ها در مدل گراف نقش براي ارضاء MAC ارائه يك سري Role Graph براي هر نمونه از كنترل دسترسي هاي مبتني بر Lattice
استفاده از RBAC براي اعمال DAC و MAC مكانيزم RBAC به اندازه اي كلي است كه بتواند MAC و DAC را شبيه سازي كند. يك خصوصيت مهم اينكه خط مشي در طول Life Cycle مي تواند تغيير كند. MAC : جريان يك طرفه اطلاعات DAC : Owner Based Administration تعريف يك سري قوانين و محدوديت ها براي شبيه سازي MAC تعريف يك سري عمليات به ازاي هر رخداد براي شبيه سازي DAC
مراجع [1] S. Oh and R. Sandhu, “A model for role administration using organization structure”, ACM SACMAT, 155-162, 2002. [2] S. Osborn, “Information flow analysis of an RBAC system”, ACM SACMAT, 163-168, 2002. [3] Chandramouli Ramaswamy and Ravi Sandhu “Role-Based Access Control Features in Commercial Database Management Systems” , 21st National Information Systems Security , Jun 2005 [4] Bertino, E.; Sandhu, R. “Database security - concepts, approaches, and challenges” , Dependable and Secure Computing, IEEE Transactions, March 2005 [5] Ravi Sandhu and Venkata Bhamidipati “An Oracle Implementation of the PRA97 Model for Permission-Role Assignment” , ACM Workshop on Role-Based Access FairFax VA , 1998 [6] He Wang and Sylvia L. Osborn "An Administrative Model for Role Graph Model" , Natural Sciences and Engineering Research Council of Canada. [7] Ravi s.Sandhu, Edward J.Coyne and Charles E.Youman, “ Role-Based Access Cotrol Models” , IEEE, 38-47, February 1996 [8] Ravi Sandhu, Venkata Bhamidipati, Edward Coyne, Sirinivas Ganta, and Charles Youman, "The ARBAC97 model for role-based administration of roles: Preliminary description and outline", In Preceeding of 2nd ACM Workshop on Role-Based Access Control, Fairfax, VA, November 6-7 1997. ACM. [9] He Wang and Sylvia L. Osborn "An Administrative Model for Role Graphs", In Data and Applications Security XVII, pages 39–44, Kluwer, 2003.
Hafez@ce.aut.ac.ir A Q & Q U E S T I O N S A N S W E R S
مشخصات RBAC در DBMSهاي تجاري Oracle Enterprise Server version 8.0 Informix Online Dynamic Server Version 7.2 Sybase Adaptive Server release 11.5 از سه جنبه مورد بررسي قرار خواهند گرفت : اعطاي نقش به کاربر پشتيباني ارتباطات و قيود در نقش امتيازات قابل اعطا
Oracle و اعطاي نقش به کاربر اوراکل ارتباط چند به چند بين کاربر و نقش را پشتيباني مي کند. PUBLIC در جملهGRANT ADMIN OPTION SET ROLE اگر نقش داراي رمز عبور باشد، بايد رمز عبور را با عبارت IDENTIFIED BY مشخص و فعال ميشود. در اوراکل مي توان بيش از يک نقش را در SET ROLE مشخص کرد. اوراکل دوگونه ديگر از جمله SET ROLE را دارد که به آن انعطاف پذيري بيشتري در فعاليت ها مي دهد: All & Except None
Oracle و پشتيباني ارتباط و قيود در نقش در اوراکل امکان دادن نقش به يک نقش در نتيجه ايجاد ساختار سلسله مراتبي نقش را دارد. گر چه نمي توان قيود اضافي يا ارتباطات را بين نقش ها در declaration تعريف کرد : بنابراين اوراکل جداسازي وظايف يا SoD را پشتيباني نمي کند. تعيين محدوديت در تعداد يا کارديناليتي نقش ها براي اعضا ممکن نيست. امكان تعريف قيود فقط تا حدي وجود دارد.
Oracle و امتيازات قابل اعطا امتيازات سيستمي حقوقي هستند که با فرمانهايي نظير CREATE SESSION و CREATE TABLE و غيره اجرا مي شوند. امتيازات شي اي به کاربران اجازه مي دهد که يک عمل خاص را روي يک جدول خاص view يا دنباله اجرا کنند. هر دو شاخه امتيازات مي توانند به نقش ها داده شوند. امتيازات سيستمي تنها مي توانند توسط DBA يا يک کاربري که اين امتياز را با ADMIN OPTION دارد منتقل شوند. امتيازات شي اي تنها مي توانند توسط صاحب شي يا کاربري که اين امتياز را با GRANT OPTION دارد منتقل شود.
مقايسه خصيصه ها در DBMS ها √ دادن امتيازشي‌اي DBMS به يک Role ۹ - دادن امتيازسيستمي DBMS به يک Role ۸ مشخص کردن حداکثر و حداقل کارديناليتي اعضاي نقش ۷ جدا کردن ديناميک وظايف و قيود روي نقش ها ۶ جدا کردن استاتيک وظايف و قيود روي نقش ها ۵ ايجاد ساختار سلسله مراتبي نقش ۴ مشخص کردن نقش فعال بطور پيش‌فرض براي کاربر ۳ داشتن چند نقش فعال براي يک کاربر در يک نشست ۲ امکان دادن نقش به ديگر کاربران توسط grantee ۱ Oracle Sybase Informix خصيصه مورد
تحليل جريان غير مجاز اطلاعات در RBAC اگر داده ها از لحاظ امنيتي چند سطحي در نظر گرفته شوند، انتساب رول ها و دسترسي ها مي تواند به گونه اي باشد كه منجر به نشت اطلاعات در بين سطوح به صورت غير مجاز گردد. الگوريتمي براي يافتن چنين انتساب هايي ارائه گرديده است تا در يك مدل كنترل دسترسي RBAC تعيين كند كه از چه داده هايي به چه داده هايي، اطلاعات منتقل مي گردد. الگوريتم FlowStart ، با در نظر گرفتن تمام مجوزهاي تمامي نقش ها ، انتشار اطلاعات ممكن، توسط فعال شدن يك نقش را معين مي كند. الگوريتم CanFlow ، همزمان فعال شدن چندين نقش يك كاربر را هم در نظر مي گيرد و دور احتمالي را در گراف حذف مي كند.