خانه محصولات حساب کاربری ثبت نام

دانلود پاورپوینت روش مديريتي كنترل دسترسي نقش مبنا و امنیت پایگاه داده (کد9631)

شناسه محصول و کد فایل : 9631

نوع فایل : Powerpoint پاورپوینت

قابل ویرایش تمامی اسلاید ها دارای اسلاید مستر برای ویرایش سریع و راحت تر

امکان باز کردن فایل در موبایل - لپ تاپ - کامپیوتر و ...

با یک خرید میتوانید بین 342000 پاورپینت ، 25 پاورپوینت را به مدت 7 روز دانلود کنید

هزینه فایل : ~~105000~~ : 54000 تومان

تماس با پشتیبانی 09164470871

توضیحات محصول دانلود پاورپوینت روش مديريتي كنترل دسترسي نقش مبنا و امنیت پایگاه داده (کد9631)

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

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

عنوان های پاورپوینت :

فهرست مطالب

امنیت پایگاه داده

مدل کنترل دسترسی نقش - مبنا

طرح یک مشکل و ارائه یک راهحل

خانواده مدل های RBAC

RBAC0 یا مدل پایه

RBAC1 یا مدل سلسله مراتب

سلسله مراتب

RBAC2 یا مدل قیود

RBAC2 یا مدل قیود ( ادامه )

RBAC3 یا مدل Consolidated

اجزاء مدل کنترل دسترسی نقش‌مبنا

مدیریت در کنترل دسترسی نقش- مبنا

مدیریت در سیستم های نقش- مبنا

مدل مدیریتی RBAC

اجزاء مدل مدیریتی RBAC

مدل URA یا مدل انتساب کاربران به نقش

مدل URA97

مدل URA97 - رابطه Can_Assign

مدل URA97

مدل URA97 - رابطه Can_Revoke

مدل PRA97 یا مدل انتساب مجوزها به نقش

مدل PRA97

مدل PRA97 - رابطه Can_AssignP

مدل PRA97

مدل PRA97 - رابطه Can_RevokeP

مدل RRA یا مدل انتساب نقش به نقش

مشکلات موجود در مدل مدیریتی ARBAC97

مدل Role Graph

اجزاء مدل Role Graph

مدیریت غیرمتمرکز در مدل Role Graph

حوزه های مدیریتی در Role Graph

ساخت گراف نقشهای مدیریتی

مدل مدیریتی RBAC توسعه یافته

ساختار سازمانی

ساخت User & Permission Pool

ساختار مدل مدیریتی RBAC توسعه یافته

اصلاح مدل با اعمال مفهوم ساختار سازمانی

اجزاء مدل ARBAC02

کنترل دسترسی نقش- مبنا و MAC

استفاده از RBAC برای اعمال DAC و MAC

مراجع

[email protected]

مشخصات RBAC در DBMSهای تجاری

Oracle و اعطای نقش به کاربر

Oracle و پشتیبانی ارتباط و قیود در نقش

Oracle و امتیازات قابل اعطا

مقایسه خصیصه ها در DBMS ها

تحلیل جریان غیر مجاز اطلاعات در RBAC

\n \n\n \n\n

\n\nقسمت ها و تکه های اتفاقی از فایل\n\n \n\nروش مدیریتی کنترل دسترسی نقش مبنا و امنیت پایگاه داده\n\n2pro.ir\n\nمدل مدیریتی کنترل دسترسی نقش مبنا و امنیت پایگاه داده\n\nفهرست مطالب\n\nامنیت پایگاه داده\n\nمدل کنترل دسترسی نقش - مبنا\n\nمدیریت در کنترل دسترسی نقش- مبنا\n\nمدل مدیریت در کنترل دسترسی نقش- مبنا\n\nپیاده سازی مدل PRA97 برای انتساب مجوز به نقش در Oracle\n\nکنترل دسترسی نقش- مبنا و MAC\n\nاستفاده از RBAC برای اعمال DAC و MAC\n\nجمع بندی\n\nمراجع\n\nامنیت پایگاه داده\n\nجنبه های مهم در برقراری امنیت\n\nکنترل دسترسی کاربران به داده ها\n\nبایستی مدلی ارائه شود تا تعیین گردد که چه دسترسی‌هایی مجاز و چه دسترسی‌هایی غیر مجاز است.\n\nپایگاههای داده با توجه به متمرکزسازی داده ها در آن بیشتر مورد توجه قرار می‌گیرند.\n\nمدل کنترل دسترسی نقش- مبنا به عنوان یک مدل کنترل دسترسی بسیار مرسوم و پرکاربرد مطرح است.\n\n...\n\n...\n\nمدل کنترل دسترسی نقش - مبنا\n\nکنترل دسترسی اجباری یا MAC\n\nکنترل دسترسی اختیاری یا DAC\n\nکنترل دسترسی نقش- مبنا یا RBAC\n\nعلت کاربرد زیاد این مدل برای کنترل دسترسی ها ( مزایا ) :\n\nسادگی مدیریت آن .\n\nنگاه واقعی مدل به محیط های عملیاتی.\n\nمجوز دسترسی بر اساس نقش ها در سازمانهاست نه بر اساس مالکیت دادهها.\n\nمدل RBAC به خوبی سیاست امنیتی پیچیده را مدیریت می‌کند.\n\nطرح یک مشکل و ارائه یک راهحل\n\nاگر سیستمی با هزاران کاربر و صدها نقش و مجوز در نظر بگیریم، مدیریت نقش‌ها و انتساب کاربران به نقش‌ها و مجوز‌ها به نقش‌ها و همچنین ساخت سلسله مراتب از نقش‌ها بسیار پیچیده و مشکل می‌گردد و نمی‌توان آن را توسط یک مدیر در سیستم انجام داد.\n\nراهکار : مدیریت غیر متمرکز.\n\nدر نظر کرفتن نقش‌های مدیریتی و حوزههای مدیریتی برای هر نقش\n\nهمچنین ایجاد سلسله مراتبی از آنها\n\nواگذاری مدیریت به افراد مختلف در حوزههای گوناگون سیستم\n\nهر مدیر مسؤولیت مدیریت در حوزه خود را بر عهده داشته باشد\n\nخانواده مدل های RBAC\n\nRBAC0 به عنوان مدل پایه در پایین دارای کمترین نیازمندیهای سیستم RBAC می باشد.\n\nRBAC1 سلسله مراتبی از نقش‌ها را به آن اضافه کرده است به طوریکه نقش‌ها می توانند از نقش‌های دیگر به ارث ببرند\n\nRBAC2 قیودی را تعریف می‌کند که محدودیت‌هایی را به تنظیمات قابل قبول برای مولفه ها در RBAC اضافه می‌نماید.\n\nمدل Consolidated ، شامل هر دو RBAC1 و RBAC2 و به صورت ضمنی، RBAC0 نیز می باشد.\n\nRBAC0 یا مدل پایه\n\nچهار مولفه :\n\nکاربران :\n\nمنظور از کاربر، انسان می باشد. فردی که با سیستم تعامل دارد.\n\nنقش ها\n\nنقش، یک کار نامدار درون سازمان است که سازمان مجوز ها و مسئولیت ها را به اعضای یک نقش می دهد.\n\nاختیارات یا مجوزها\n\nبه کسی که دارنده اختیار است، قدرت انجام یک عمل در سیستم را می دهد.\n\nنشست ها\n\nکاربر با فعال کردن یک مجموعه از نقش ها که به او متعلق است، نشست ها را برقرار می‌کند.\n\nRBAC1 یا مدل سلسله مراتب\n\nسلسلهمراتب به معنی ساختار نقش‌ها‌ست که حدود مجوزها و مسئولیت‌ها در سازمان را باز‌می‌تاباند.\n\nاین سلسلهمراتب یک مجموعه ترتیب جزئی است. یک ترتیب جزئی، خواص بازتابی، انتقالی و پاد تقارنی را داراست.\n\nسلسله مراتب\n\nمحدود کردن وراثت\n\nممکن است بخواهید تعدادی اختیارات محرمانه برای خود داشته باشد و از به ارث رسیدن آنها به سایر نقش‌ها جلوگیری کنید.\n\nزیر ...........\n\nقیود جنبه مهمی از RBAC هستند. یک مثال رایج جدا کردن نقش های سازمان است.\n\nنقش های انحصار متقابل :\n\nیک کاربر می تواند به حداکثر یک نقش در مجموعه انحصار متقابل نسبت داده شود. که این قیود باعث جدا کردن وظایف از یکدیگر می شود.\n\nانحصار متقابل در مورد PA ، مشخص می کند که یک اختیار خاص نتواند به دو نقش نسبت داده شود.\n\nدانه بندی :\n\nیک قید دیگر روی کاربر است . حداکثر تعداد اعضای یک نقش می تواند محدود باشد. تنها یک نفر می تواند رئیس یک سازمان باشد.\n\nتعداد نقش های یک کاربر می تواند به مجموعه خاصی محدود شود و یا به تعداد خاصی محدود گردد.\n\nRBAC2 یا مدل قیود ( ادامه )\n\nنقشهای پیش شرط :\n\nایده آن مبتنی بر شایستگی‌ها است، به طوریکه کاربر می تواند به نقش A نسبت داده شود و اگر تنها اگر کاربر قبلا به نقش B نسبت داده شده باشد.\n\nبرای سازگاری..........\n\n3 = 1 + 2\n\nتلفیق این دو، موارد قابل بحث جدیدی را بوجود می آورد :\n\nقیود روی سلسله مراتبی از نقشها :\n\nچون قیود و سلسله مراتب هر دو در مدل دیده می شوند ، قیود را روی سلسله مراتب هم می‌توان تعریف کرد.\n\nقیود می‌توانند تعداد نقش‌های بالاتر و پایین تر را محدود کند.\n\nتقابلات :\n\nتقابل ظریفی بین قیود و سلسله مراتب بوجود می آید.\n\nنقش های محرمانه :\n\nنقش های محرمانه می توانند بدون هیچ برخورد و تلاقی، انحصار متقابل باشند.\n\nاجزاء مدل کنترل دسترسی نقش‌مبنا\n\nالمان‌های مدل RBAC\n\n \n\nکاربران U\n\nنقش‌ها R\n\nمجوزها P\n\nجلسهها S\n\nمحدودیت‌ها C\n\nسلسله مراتب نقش‌ها RH\n\nمدیریت در کنترل دسترسی نقش- مبنا\n\nدر سیستم بزرگ که تعداد نقش‌ها به صدها و هزاران افزایش می‌یابد، مدیریت این نقش ها و روابط میان آنها یک کار سخت که به صورت مرکزی انجام می‌شود و به گروه کوچکی از مدیران امنیتی محول می‌گردد.\n\nاز آنجا که نکته اصلی .........\n\nمدیریت در سیستم های نقش- مبنا\n\nپروژه تحقیقاتی European Union :\n\nپروژه Webocracy و سیستم Web-Based مربوطه\n\nاهداف :\n\nفراهم آوردن سرویس های دولتی\n\nQuality Of Service\n\n…\n\nماجول CSAP\n\nCommunication, Security, Authentication, Privacy\n\nماجول CAC به عنوان ابزار مدیریت ماجول فوق\n\nCSAP Administration Console\n\nمدل مدیریتی RBAC\n\nانواع مدل های بحث شده، برای مدیر نیز مطرح است. البته معمولا مدل مدیر ساده تر از خود مدل RBAC است. بنابراین می توان از RBAC0 به جای RBAC3 استفاده نمود.\n\nچگونه مدل سلسله مراتبی مدل مدیر مدیریت می شود؟\n\nبه طور تئوریک، سطح دوم از سلسله مراتب می تواند برای مدیریت سطح اول مورد استفاده قرار گیرد. ولی برای مدل ضروری نمی باشد.\n\nمدیریت سلسله مراتب مدیر می‌تواند توسط یک نفر رئیس سیستم مدیریت انجام شود. مجوزهای مدیر در RBAC توانایی تغییر نسبت دادن نقش به کاربران و نیز تغییر دادن نسبت دادن اختیارات به نقش ها و روابط موجود در سلسله مراتب نقش ها را به وجود آورد.\n\nاجزاء مدل مدیریتی RBAC\n\nاجزاء مدل مدیریتی RBAC\n\nاین مدل در سال 1997 توسط Sandhu ارائه گردید. ایده اصلی آن استفاده از خود مدل RBAC برای مدیریت آن بود. این مدل شامل سه مدل اصلی به شرح زیر می باشد :\n\n \n\nمدل URA یا مدل انتساب کاربران به نقش\n\nمدل PRA یا مدل انتساب مجوزها به نقش\n\nمدل PRA یا مدل انتساب نقش به نقش\n\nمدل URA یا مدل انتساب کاربران به نقش\n\nاین مدل دارای 2 مؤلفه اصلی است :\n\nانتساب کاربران به نقش ها یا مدل Gant Can-assign\n\nباز پس گیری عضویت آنها در نقش ها یا Revoke Can-revoke\n\n \n\nرابطه Can-assign بیان می‌کند که چه افرادی با چه پیش‌شرط‌هایی می‌توانند در چه حوزهای کار اعطاء را انجام دهند. افراد را با نقش‌های مدیریتی که دارا هستند معین می کند. یعنی نقشی را بیان می کند که افراد برای اعمال کارهای مدیریتی در یک حوزه خاص باید دارا باشند.\n\n \n\nرابطه Can-revoke بیان می‌کند که چه افرادی در چه حوزههایی می‌توانند عمل بازپس‌گیری را انجام دهند. این توابع برای عمل انتساب و بازپس‌گیری نقش ها به کاربران به کار می‌رود و بایستی در هر عمل، امکان انجام آنرا توسط آنها چک کرد.\n\nمدل URA97\n\nتابع Can_assign دارای سه پارامتر ورودی است X که نقش مدیریتی فردی که می خواهد عمل انتساب را انجام دهد را مشخص می کند. Y نقش پیش شرط فردی است که می خواهیم به او نقش را انتساب دهیم و Z که دامنه نقش های قابل انتساب را معین می ................\n\nمدل URA97\n\nتابع Can_Revoke دارای دو پارامتر ورودی است. X که نقش مدیریتی فردی که می خواهد عمل بازپس گیری نقش را انجام دهد را مشخص می کند. Z دامنه نقش هایی را که می تواند بازپس گیرد تعیین می کند . هیچ پیش شرطی برای این تابع تعریف نمی گردد.\n\nمدل URA97 - رابطه Can_Revoke\n\nسطر دوم این جدول بیان می‌‌کند که "کارشناس امنیتی بخش متقاضیان و مشترکین" می‌‌تواند از تمام کاربران سیستم, نقش "کارشناس سیستم متقاضیان و مشترکین" (CC) , "کارشناس امور متقاضیان" (RO) و "کارشناس امور مشترکین" (CO) را بازپس‌گیرد.\n\nمدل PRA97 یا مدل انتساب مجوزها به نقش\n\nاین مدل نیز مشابه مدل قبلی دارای 2 مؤلفه اصلی است :\n\nمدل Grant برای اعطاء مجوزها به نقش ها Can-assignp\n\nمدل Revoke برای بازپس گیری مجوز از نقش ها Can-revokep\n\n \n\nرابطه اول وظیفه تعیین افراد و شرط ها برای انجام عمل انتساب در یک حوزه خاص و رابطه دوم وظیفه تعیین افراد برای انجام عمل بازپس گیری در یک حوزه خاص را بر عهده دارد.\n\nمدل PRA97\n\nتابع Can_Assignp دارای سه پارامتر ورودی است . X که نقش مدیریتی مجری عمل انتساب را مشخص می کند. Y نقش ای است که می توان مجوزهای آن را برای عمل انتساب انتخاب کرد. Z ، حوزه نقش هایی است که می توان مجوز انتخاب شده را به آن نسبت داد.\n\nمدل PRA97 - رابطه Can_AssignP\n\nسطر اول این جدول بیان می‌دارد که کاربری با نقش "کارشناس امنیتی امور رایانه" (CS) یا "مدیرکل امنیتی" (SSO) می‌‌تواند تمام مجوز‌‌های صریح و ضمنی نقش "مدیرعامل اداره رایانه" (CDM) یعنی در واقع تمام مجوزهای موجود در سیستم را به نقش "ریاست سیستم صورتحساب‌‌گیری" (BCM) عطا کند.\n\nمدل PRA97\n\nتابع Can_Revokep دارای دو پارامتر ورودی است که x نقش مدیریتی مجری عمل بازپس گیری و z حوزه نقش هایی است که می توان در آن ح..............\n\nسطر اول این جدول بیان می‌‌کند که "کارشناس امنیتی سیستم صورتحساب‌‌گیری" (BCS) و طبیعتا "کارشناس امنیتی امور رایانه" (CS) و "مدیرکل امنیتی" (SSO) می‌‌توانند هر مجوزی را از "کارشناس صورتحساب‌‌ها" (BO) و "کارشناس وصولی‌‌ها" (PO) بازپس‌‌گیرند.\n\nمدل RRA یا مدل انتساب نقش به نقش\n\nایجاد یک سلسله مراتب از نقش ها\n\nفراهم آوردن بستری برای ساخت مدل RBAC1\n\n \n\nوقتی نقشی، بالاتر از یک نقش دیگر قرار می گیرد، تمام مجوزهای نقش قبلی را به ارث می برد. یعنی نقش بالاتر تمام مجوزهای نقش پایین تر را داراست علاوه بر آن یک سری مجوز های خاص خود را نیز دارد. این مدل سلسله مراتبی با توجه به ساختار سلسله مراتبی نقش های سازمانی می تواند شکل بگیرد و به هر چه بهتر مدل کردن نقش ها و نقش های مدیریتی موجود سازمان در سیستم کمک کند.\n\nمشکلات موجود در مدل مدیریتی ARBAC97\n\nضعف‌های مدل URA 97\n\nانتساب چندمرحله‌ای نقش به کاربر\n\nاطلاعات انتسابات نقش به کاربر تکراری\n\nمحدودیت در مفهوم User Pool\n\n \n\nضعف‌های مدل PRA97\n\nانتساب چندمرحله‌ای مجوز به نقش\n\nاطلاعات انتسابات مجوز به نقش تکراری\n\nمحدودیت در مفهوم Permission Pool\n\nعدم امکان تعریف محدودیت در مفهوم Permission Pool\n\nاثر جانبی ناخواسته (انتساب به خارج از حوزه مدیریتی)\n\nمدل Role Graph\n\nاز دید دیگر مدل کنترل دسترسی نقش مبنا را مبتنی بر سه گراف در سه حوزه مختلف بررسی می کنند :\n\nگراف اختیارات یا مجوز ها :\n\nاین گراف بیانگر سلسله مراتب حاکم برانواع مجوزهای مختلف است. ممکن است داشتن یک مجوز ، داشتن یک مجوز دیگر را ایجاب کند.\n\nگراف گروه ها یا کاربران :\n\nدر این گراف کاربران یا گروهای کاربری و سلسله مراتب آنها نمایش داده می شود.\n\nگراف نقش ها یاRole Graph :\n\nدر این گراف نقش های موجود سیستم ، گره های گراف را تشکیل می دهند و خط بین آنها ارتباط شامل شدن را معین می کند.\n\nاجزاء مدل Role Graph\n\nمدیریت غیرمتمرکز در مدل Role Graph\n\nمطابق همین دید به مدل کنترل دسترسی ، گراف نقش های مدیریتی نیز قابل ترسیم است. این گراف شامل نقش های عادی و نقش های مدیریتی است و دو رابطه در آن تعریف می گردد :\n\nرابطه Is-Junior رابطه ای بین نقش های عادی و یا بین نقش های مدیریتی است. این رابطه نشان دهنده شامل بودن یک نقش بر نقش دیگر است.\n\nرابطه دوم، رابطه Administrates است که با خط های خط چین در شکل نشان داده شده است.\n\nاین گراف دارای دو گره به نامهای MinRole و MaxRole و SSO که وظیفه مدیریت کل سیستم را بر عهده دارد ، در نظر گرفته می شود.\n\nحوزه های مدیریتی در Role Graph\n\nساخت گراف نقشهای مدیریتی\n\nمطابق شکل a در ابتدا سه نقش و یک حوزه مدیریتی کلی با مدیریت SSO وجود دارد .\n\nمطابق شکل b بخشها به تدریج اضافه می شوند و گراف بزرگتر می شود.\n\nمدل مدیریتی RBAC توسعه یافته\n\nسعی شده است مشکلات مطرح شده، در مدل توسعه یافته یعنی ARBAC02 حل گردند. در این مدل مفاهیم User Pool و Permission Pool مطرح می شود و سعی می گردد تا با حل تداخل های غیرلازم موجود ، مشکلات مطرح شده کنار گذاشته شود.\n\nبرای غلبه بر مشکلات مطرح شده در مدل قبل، دو استراتژی در این مدل اتخاذ شده است:\n\nاول، از ساختار سازمانی به عنوان User pool و Permission pool استفاده می شود به جای اینکه از پیش شرط هایی در سلسله مراتب نقش ها استفاده کرد.\n\nدوم، توسط این ساختار سازمانی یک روند پائین به بالا برای انتساب مجوز ها به نقش ها مطرح میشود.\n\nساختار سازمانی\n\nبرای توسعه سیستم های اطلاعاتی،"سازمان" یک مفهوم خوب برای تحلیل فعالیت های موجود در هر دامنه است.\n\nساختار سازمانی یک ساختار درختی با ویژگی سلسله مراتبی است. این ساختار از المان های سازمانی تشکیل می شود که افراد متعلق به هر یک دارای یک هدف مشترک در سازمان هستند و یک سری فعالیتهای خاص برای رسیدن به آنها انجام می دهند.\n\nکارهای انجام یافته با داده های مورد دسترسی ارتباط مستقیم دارد. پس فعالیت ها و کارهای یک بخش با مجوز های آن ارتباط دارد. پس می توان واحد سازمانی را به عنوان یک گروه از کاربران و مجوز ها برای رسیدن به هدف خاص تعریف کرد.\n\nساخت User & Permission Pool\n\nحال مدیر های امنیتی، کاربران و مجوزهای موجود در هر واحد سازمانی را به نقش ها نسبت می دهند.\n\nساختار مدل مدیریتی RBAC توسعه یافته\n\nاصلاح مدل با اعمال مفهوم ساختار سازمانی\n\nتوابع Can_Assign و Can_Assignp همان توصیف موجود در ARBAC97 را دارا هستند و فقط پیش شرط ها در آن مجددا تعریف شده است :00000000000000\n\nپیش شرط ها در PRA یک عبارت منطقی از عملگر های And و Or روی عبارات x و ~x است که x یک نقش عادی یا یک داحد سازمانی ذر ساختار سازمانی تهیه شده توسط گروه IT یا Permission Pool است.\n\nاجزاء مدل ARBAC02\n\nساخت Permission Pool با یک ساختار سازمانی به نام OS-P\n\nساخت User Pool با یک ساختار سازمانی به نام OS-U\n\nکنترل دسترسی نقش- مبنا و MAC\n\nRole Graph Model\n\nیال در گراف نقش و رابطه Is Junior\n\nالگوریتم ساخت گراف\n\nخصوصیات گراف نقش\n\nتعریف یک سری شرایط محدودیت ها در مدل گراف نقش برای ارضاء MAC\n\nارائه یک سری Role Graph برای هر نمونه از کنترل دسترسی های مبتنی بر Lattice\n\nاستفاده از RBAC برای اعمال DAC و MAC\n\nمکانیزم RBAC به اندازه ای کلی است که بتواند MAC و DAC را شبیه سازی کند.\n\nیک خصوصیت مهم اینکه خط مشی در طول Life Cycle می تواند تغییر کند.\n\nMAC : جریان یک طرفه اطلاعات\n\nDAC : Owner Based Administration\n\nتعریف یک سری قوانین و محدودیت ها برای شبیه سازی MAC\n\nتعریف یک سری عملیات به ازای هر رخداد برای شبیه سازی DAC\n\nمراجع\n\n[1] S. Oh and R. Sandhu, “A model for role administration using organization structure”, ACM SACMAT, 155-162, 2002.\n\n[2] S. Osborn, “Information flow analysis of an RBAC system”, ACM SACMAT, 163-168, 2002.\n\n[3] Chandramouli Ramaswamy and Ravi Sandhu “Role-Based Access Control Features in Commercial Database Management Systems” , 21st National Information Systems Security , Jun 2005\n\n[4] Bertino, E.; Sandhu, R. “Database security - concepts, approaches, and challenges” , Dependable and Secure Computing, IEEE Transactions, March 2005\n\n[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\n\n[6] He Wang and Sylvia L. Osborn "An Administrative Model for Role Graph Model" , Natural Sciences and Engineering Research Council of Canada.\n\n[7] Ravi s.Sandhu, Edward J.Coyne and Charles E.Youman, “ Role-Based Access Cotrol Models” , IEEE, 38-47, February 1996\n\n[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.\n\n[9] He Wang and Sylvia L. Osborn "An Administrative Model for Role Graphs", In Data and Applications Security XVII, pages 39–44, Kluwer, 2003.\n\[email protected]\n\nمشخصات RBAC در DBMSهای تجاری\n\nOracle Enterprise Server version 8.0\n\nInformix Online Dynamic Server Version 7.2\n\nSybase Adaptive Server release 11.5\n\nاز سه جنبه مورد بررسی قرار خواهند گرفت :\n\nاعطای نقش به کاربر\n\nپشتیبانی ارتباطات و قیود در نقش\n\nامتیازات قابل اعطا\n\nOracle و اعطای نقش به کاربر\n\nاوراکل ارتباط چند به چند بین کاربر و نقش را پشتیبانی می کند.\n\nPUBLIC در جملهGRANT\n\nADMIN OPTION\n\nSET ROLE\n\nاگر نقش دارای رمز عبور باشد، باید رمز عبور را با عبارت IDENTIFIED BY مشخص و فعال میشود.\n\nدر اوراکل می توان بیش از یک نقش را در SET ROLE مشخص کرد.\n\nاوراکل دوگونه دیگر از جمله SET ROLE را دارد که به آن انعطاف پذیری بیشتری در فعالیت ها می دهد:\n\nAll & Except\n\nNone\n\nOracle و پشتیبانی ارتباط و قیود در نقش\n\nدر اوراکل امکان دادن نقش به یک نقش در نتیجه ایجاد ساختار سلسله مراتبی نقش را دارد. گر چه نمی توان قیود اضافی یا ارتباطات را بین نقش ها در declaration تعریف کرد :\n\nبنابراین اوراکل جداسازی وظایف یا SoD را پشتیبانی نمی کند.\n\nتعیین محدودیت در تعداد یا کاردینالیتی نقش ها برای اعضا ممکن نیست.\n\nامکان تعریف قیود فقط تا حدی وجود دارد.\n\nOracle و امتیازات قابل اعطا\n\nامتیازات سیستمی حقوقی هستند که با فرمانهایی نظیر CREATE SESSION و CREATE TABLE و غیره اجرا می شوند.\n\nامتیازات شی ای به کاربران اجازه می دهد که یک عمل خاص را روی یک جدول خاص view یا دنباله اجرا کنند.\n\nهر دو شاخه امتیازات می توانند به نقش ها داده شوند. امتیازات سیستمی تنها می توانند توسط DBA یا یک کاربری که این امتیاز را با ADMIN OPTION دارد منتقل شوند. امتیازات شی ای تنها می توانند توسط صاحب شی یا کاربری که این امتیاز را با GRANT OPTION دارد منتقل شود.\n\nمقایسه خصیصه ها در DBMS ها\n\nتحلیل جریان غیر مجاز اطلاعات در RBAC\n\nاگر داده ها از لحاظ امنیتی چند سطحی در نظر گرفته شوند، انتساب رول ها و دسترسی ها می تواند به گونه ای باشد که منجر به نشت اطلاعات در بین سطوح به صورت غیر مجاز گردد.\n\nالگوریتمی برای یافتن چنین انتساب هایی ارائه گردیده است تا در یک مدل کنترل دسترسی RBAC تعیین کند که از چه داده هایی به چه داده هایی، اطلاعات منتقل می گردد.\n\nالگوریتم FlowStart ، با در نظر گرفتن تمام مجوزهای تمامی نقش ها ، انتشار اطلاعات ممکن، توسط فعال شدن یک نقش را معین می کند.\n\nالگوریتم CanFlow ، همزمان فعال شدن چندین نقش یک کاربر را هم در نظر می گیرد و دور احتمالی را در گراف حذف می کند.\n\nبا تشکر از توجه شما\n\nتو پروژه\n\n2pro.ir\n\n \n\n \n\n۳۰ تا ۷۰ درصد پروژه / پاورپوینت / پاور پوینت / سمینار / طرح های کار افرینی / طرح توجیهی / پایان نامه/ مقاله ( کتاب ) های اماده به صورت رایگان میباشد