متن خبر

نحوه پیاده سازی کنترل دسترسی مبتنی بر رابطه (ReBAC)

نحوه پیاده سازی کنترل دسترسی مبتنی بر رابطه (ReBAC)

شناسهٔ خبر: 456637 -




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

روش‌های سنتی کنترل دسترسی، مانند کنترل دسترسی مبتنی بر نقش (RBAC)، نقش‌های خاصی را به کاربران اختصاص می‌دهند. در حالی که این در بسیاری از موارد کار می کند، می تواند دشوار شود، به خصوص در محیط های پویا که در آن نقش ها و مجوزها نیاز به تطبیق سریع دارند. از سوی دیگر، کنترل دسترسی مبتنی بر ویژگی (ABAC) انعطاف‌پذیری را بر اساس آپشن های کاربر ارائه می‌دهد، اما مدیریت آن می‌تواند پیچیده باشد.

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

در پایان این آموزش، شما درک روشنی از ReBAC خواهید داشت و می توانید یک سناریوی ReBAC را مدل کنید.

خوراکی های کلیدی

اصول ReBAC: درک کنید که چگونه ReBAC از روابط بین موجودیت ها برای کنترل دسترسی استفاده می کند که با مدل های سنتی متفاوت است.

تجسم خط مشی: در مورد نمایش خط مشی ها به عنوان نمودار برای مدیریت واضح تر بیاموزید.

مثال های دنیای واقعی: برنامه ReBAC را در سناریوهایی مانند پلتفرم های رسانه های اجتماعی و ابزارهای مدیریت پروژه کاوش کنید.

مزایای ReBAC: مزایایی مانند کنترل دانه ای و تطبیق سیاست پویا را کشف کنید.

مدل‌های مجوز: با مدل‌های رایج ReBAC مانند مدل‌های مالکیت و سلسله مراتبی آشنا شوید.

پیاده سازی Permify: راهنمای گام به گام برای پیاده سازی ReBAC در Permify، از جمله تعریف موجودیت، ایجاد رابطه و راه اندازی مجوزها.

کنترل دسترسی مبتنی بر رابطه (ReBAC) چیست؟

روش‌های سنتی کنترل دسترسی، مانند کنترل دسترسی مبتنی بر نقش (RBAC)، نقش‌های خاصی را به کاربران اختصاص می‌دهند، مانند دادن نشانی که روی آن «مدیر» یا «کارمند» نوشته شده است. اما اگر نقش ها چندان واضح نباشد و روابط بین افراد و منابع اهمیت بیشتری داشته باشد، چه؟

اینجاست که کنترل دسترسی مبتنی بر رابطه (ReBAC) وارد عمل می‌شود. ReBAC به جای تکیه بر نقش‌ها یا آپشن های از پیش تعریف‌شده، شبکه پیچیده ارتباطات بین کاربران، منابع و سایر موجودیت‌ها را در نظر می‌گیرد. مانند این است که بگویید، "شما می توانید به این دسترسی دسترسی داشته باشید، زیرا به این روش خاص به آن متصل هستید"، نه اینکه فقط بر اساس یک برچسب عمومی باشد.

اما واقعا ReBAC چگونه این کار را انجام می دهد؟ ReBAC روابط بین موجودیت ها، مانند کاربران و منابع را تحلیل می کند و از این ارتباطات برای تعیین دسترسی استفاده می کند.

بیایید آن را بیشتر تجزیه کنیم. در زندگی روزمره ما روابط مهمی داریم. به رسانه های اجتماعی فکر کنید – می توانید پست های خاصی را ببینید زیرا با شخصی دوست هستید یا به این دلیل که شخصی که دنبال می کنید آن را پسندیده است. ReBAC این ایده را می گیرد و آن را برای کنترل دسترسی در سیستم ها به کار می گیرد.

خط مشی به عنوان یک نمودار

در هسته ReBAC مفهوم "سیاست به عنوان یک نمودار" نهفته است. این ایده اهمیت تجسم سیاست های دسترسی را از طریق روابط نشان می دهد.

تصور کنید که نقشه ای دقیق از یک شهر شلوغ دارید. این فقط ساختمان ها را نشان نمی دهد، بلکه ارتباطات بین آنها را نیز نشان می دهد - جاده ها، پل ها و مسیرهایی که همه چیز را به هم مرتبط می کند.

اکنون، این نقشه را به عنوان نماینده سازمان خود تصور کنید. به جای ساختمان ها، اعضای تیم، بخش ها و نقش آنها را نشان می دهد. ارتباطات بین آنها نماد روابطی است که دسترسی را دیکته می کند.

این همان چیزی است که ما از "خط مشی به عنوان یک نمودار" در ReBAC می گوییم.

به عبارت ساده تر، سیاست های دسترسی مانند نقاط به هم پیوسته در یک نمودار هستند. هر نقطه نشان دهنده یک موجودیت است و خطوط بین آنها نشانگر روابط مؤثر بر مجوز است. این یک نمایش بصری است که به ما کمک می کند تا شبکه پیچیده ای از اتصالات را که دسترسی را کنترل می کند، درک کنیم.

ReBAC چه تفاوتی با سایر مدل های کنترل دارد؟

اکنون، بیایید تحلیل کنیم که چگونه ReBAC خود را از سایر مدل‌های کنترل دسترسی، مانند کنترل دسترسی مبتنی بر نقش (RBAC) متمایز می‌کند.

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

استخراج نقش: ReBAC اجازه می دهد تا سیاست های مجوز را بر اساس روابط از قبل موجود ایجاد کنید. این بدان معناست که اختصاص دادن یک نقش خاص به یک کاربر در یک زمینه ممکن است به طور خودکار آن نقش را به نهادهای مرتبط گسترش دهد و نیاز به تخصیص دستی را کاهش دهد.

نقش های منبع: برخلاف نقش های جهانی در مدل های سنتی، ReBAC مفهوم نقش های خاص منبع را معرفی می کند (به عنوان مثال: Folder#Owner). این نقش‌ها منحصر به زمینه یک منبع خاص هستند و تضمین می‌کنند که مجوزها مربوط و متناسب با آن موجودیت خاص هستند.

نمونه های دنیای واقعی

برای درک بهتر نحوه عملکرد کنترل دسترسی مبتنی بر رابطه (ReBAC) در دنیای واقعی، بیایید دو سناریو را تحلیل کنیم که پیچیدگی‌های روزمره را تقلید می‌کنند.

این مثال‌ها به نشان دادن چگونگی برتری ReBAC در مدیریت پویایی دسترسی پیچیده کمک می‌کند.

پلتفرم اجتماعی شبیه اینستاگرام

یک پلتفرم الهام گرفته از اینستاگرام را در نظر بگیرید که در آن کاربران حساب های شخصی دارند. هر حساب شامل محتوای تولید شده توسط کاربر، یعنی تصاویر (تصویر 1 و عکس 2)، تعاملات چت با کاربران مختلف و همکاری پروژه است.

حساب کاربری دارای فهرست ی از کاربران مسدود شده است که برای مشاهده تصاویر محدود شده اند. در اینجا یک تفکیک دقیق از نهادها و مجوزها آمده است:

1. نهادهای حساب

حساب کاربری: نشان دهنده حساب های کاربری فردی در پلت فرم است.

تصاویر (تصویر 1 و عکس 2): محتوای بصری تولید شده توسط کاربر را به تصویر بکشید.

چت: تاریخچه تعامل با کاربران مختلف را ضبط می کند.

فهرست کاربران مسدود شده: فهرستی از کاربرانی را که از مشاهده تصاویر مسدود شده اند نگهداری می کند.

2. دینامیک مجوزها

مجوزهای دسترسی به حساب:

"Account#Owner" مالکیت را اعطا می کند و به دارنده حساب کاربری اجازه می دهد تمام جنبه ها را مدیریت کند.

"Account#Viewer" به دیگران امکان می دهد تا حساب کاربر را مشاهده کنند.

مجوزهای مدیریت تصویر:

"Picture#Owner" مالکیت را در سطح تصویر مشخص می کند و به کاربر امکان ویرایش، حذف و آپلود تصاویر را می دهد.

"Picture#Viewer" به بینندگان عادی اجازه می دهد فقط تصاویر را مشاهده کنند.

"BlockedUser#CannotView" تضمین می کند که کاربران مسدود شده نمی توانند تصاویر را مشاهده کنند.

مجوزهای تعامل چت:

"Chat#Participant" به کاربران امکان می دهد در تعاملات چت شرکت کنند.

"Chat#BlockedUser" کاربران خاصی را از شرکت در چت ها محدود می کند.

مجوزهای ویرایش حساب:

"Account#Edit" امکان به روز رسانی جزئیات و تنظیمات برگزیده حساب را اعطا می کند.

Instagram.png
نهادهای پلتفرم اجتماعی مانند اینستاگرام

در این سناریو، نماد "#" نشان دهنده رابطه بین موجودیت ها هنگام تعریف مجوزها است. به عنوان مثال، "Account#Owner" به معنای مالکیت حساب کاربری است که به دارنده حساب اجازه می دهد تا تمام جنبه های حساب خود را مدیریت کند.

ابزار مدیریت پروژه

یک ابزار مدیریت پروژه را تصور کنید که در آن تیم ها در پروژه های مختلف با یکدیگر همکاری می کنند. موجودیت‌هایی مانند «تیم‌ها»، «پروژه‌ها» و «وظایف» نقش‌های اصلی را ایفا می‌کنند و سازگاری ReBAC را نشان می‌دهند:

1. نهادهای تیم:

تیم ها: نماینده گروه های مشارکتی در ابزار مدیریت پروژه.

پروژه ها: شامل ابتکارات مختلف در حال انجام است.

وظایف: فعالیت های پروژه را به وظایف قابل مدیریت تقسیم کنید.

2. پویایی مجوزها:

مجوزهای رهبری تیم:

"Team#Lead" رهبری تیم را تعیین می کند و به رهبران اجازه می دهد تا فعالیت های مرتبط با تیم را مدیریت کنند.

مجوزهای مالکیت پروژه:

"Project#Owner" به معنای مالکیت در سطح پروژه است که کنترل همه جانبه را بر اقدامات مرتبط با پروژه اعطا می کند.

مجوزهای تعیین تکلیف:

«وظیفه#مسئول» افرادی را تعیین می‌کند که مسئول وظایف خاص هستند.

project.png
نهادهای ابزار مدیریت پروژه

این سناریوهای دنیای واقعی تطبیق پذیری و اثربخشی ReBAC را در مدیریت کنترل دسترسی در تنظیمات مختلف نشان می دهد.

مزایای ReBAC

حال، بیایید بفهمیم که چرا کنترل دسترسی مبتنی بر رابطه (ReBAC) از روش‌های سنتی مانند کنترل دسترسی مبتنی بر نقش (RBAC) و کنترل دسترسی مبتنی بر ویژگی (ABAC) متمایز است. ReBAC مجموعه ای از مزایا را به ارمغان می آورد که مقیاس پذیری، انعطاف پذیری و سازگاری را در تنظیمات سازمانی پیچیده افزایش می دهد. بیایید نگاهی دقیق تر به مزایای اصلی آن بیندازیم:

کنترل گرانول و متنی

ReBAC به سازمان‌ها اجازه می‌دهد تا کنترل‌های دسترسی دانه‌ای را متناسب با روابط خاص بین کاربران، منابع و موجودیت‌ها تعریف کنند. این تضمین می‌کند که مجوزها به صورت متنی مرتبط هستند، و سطح متفاوتی از کنترل را ارائه می‌دهند.

مدیریت کارآمد سلسله مراتب

در سناریوهایی با ساختارهای سلسله مراتبی، ReBAC مدیریت کنترل دسترسی را ساده می کند. با اجازه دادن به مجوزها برای به ارث بردن بر اساس روابط، نیاز به تخصیص نقش دستی را کاهش می دهد.

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

مقیاس پذیری و سازگاری

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

بدون مدیریت صحیح، این می تواند به خطرات امنیتی و هزینه های اداری منجر شود. با این حال، مقیاس‌پذیری ReBAC تضمین می‌کند که کنترل‌های دسترسی موثر باقی می‌مانند، این چالش‌ها را کاهش می‌دهد و از نیاز به تغییرات گسترده اجتناب می‌کند.

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

مدل های مجوز نوع رابطه رایج

بیایید به برخی از مدل های مجوز نگاه کنیم:

مدل لگن صاحبان

مدل مالکیت در ReBAC یک مفهوم اساسی است که در آن روابط مالکیت مجوز را در ساختارهای سلسله مراتبی ساده می کند.

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

سناریویی را در یک بستر ذخیره سازی ابری تصور کنید که در آن کاربران پوشه هایی را برای سازماندهی فایل های خود ایجاد می کنند. در مدل مالکیت، کاربری که یک پوشه ایجاد می کند به عنوان مالک تعیین می شود.

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

این ساختار مالکیت سلسله مراتبی، مدیریت مجوز را ساده می کند و پویایی مالکیت در دنیای واقعی را منعکس می کند.

والد-کودک و مدل هیرکال

مدل والدین-فرزند و سلسله مراتبی ابزاری قدرتمند برای مدیریت کنترل دسترسی در ساختارهای سلسله مراتبی مانند چارچوب های سازمانی یا سیستم های فایل است.

در این مدل، مجوزهایی در سطح والدین به نهادهای فرزند آن اعطا می‌شود و سیستم مجوز منسجم و کارآمد را تضمین می‌کند.

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

این جریان سلسله مراتبی مجوزها ساختار سازمانی را منعکس می کند و مدیریت کنترل دسترسی در سطوح مختلف را آسان می کند.

مدل گروه‌ها و تیم‌های کاربر

مدل گروه‌های کاربری و تیم‌ها امکان مدیریت کارآمد مجوز را با گروه‌بندی کاربران بر اساس آپشن های مشترک یا وابستگی‌های پروژه فراهم می‌کند.

در این مدل، مجوزهای اختصاص داده شده به یک رهبر گروه، به عنوان مثال، می تواند بدون زحمت برای همه اعضای آن گروه اعمال شود.

در یک ابزار مدیریت پروژه مشارکتی، تیم ها به عنوان گروه های کاربر عمل می کنند. با استفاده از مدل گروه‌ها و تیم‌های کاربر ReBAC، مجوزهای سرپرست تیم، مانند ویرایش یا حذف وظایف پروژه، می‌تواند به‌طور خودکار توسط همه اعضای تیم به ارث برسد.

این رویکرد ساده کنترل دسترسی را در محیط های مشارکتی ساده می کند، جایی که مجوزهای مبتنی بر تیم برای کارایی پروژه بسیار مهم هستند.

این سه مدل کنترل دسترسی مبتنی بر رابطه، انعطاف‌پذیری و سازگاری ReBAC را در مدیریت ساختارهای سازمانی متنوع و حوزه‌های کاربردی نشان می‌دهند.

با تراز کردن مجوزها با روابط ذاتی بین موجودیت ها، ReBAC یک چارچوب کنترل دسترسی بصری و قدرتمند را ارائه می دهد.

نحوه پیاده سازی ReBAC با Permify

حالا بیایید ReBAC را با استفاده از Permify به صورت عملی پیاده سازی کنیم.

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

Permify از یک زبان دامنه خاص برای ایجاد مدل های مجوز استفاده می کند و یک محیط Playground را برای آزمایش این مدل ها ارائه می دهد.

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

ما سناریویی ایجاد خواهیم کرد که هر دو مدل مالکیت و والدین-فرزند و سلسله مراتب را پوشش می دهد.

ما از Permify Playground برای مدل سازی استفاده خواهیم کرد.

مدل سازی

مدل سازی در Permify شامل ایجاد یک طرح است که روابط و مجوزهای بین موجودیت های مختلف در سیستم شما را تعریف می کند.

در اینجا یک فرآیند ساده شده است:

    تعریف نهادها : با ایجاد موجودیت هایی شروع کنید که منابع موجود در سیستم شما را نشان می دهند (به عنوان مثال: کاربران، سازمان ها، تیم ها).

    تعریف روابط : روابط بین این موجودیت ها برقرار کنید. به عنوان مثال، یک سازمان می تواند اعضا و مدیران داشته باشد یا یک تیم می تواند بخشی از یک سازمان باشد.

    تعریف اقدامات و مجوزها : اقداماتی را که می توان روی هر موجودیت انجام داد و شرایطی که تحت آن مجاز هستند را مشخص کنید. به عنوان مثال، فقط مدیران می توانند یک سازمان را حذف کنند.

Permify از زبان خاص خود برای مدل‌سازی منطق مجوز استفاده می‌کند و ساختارهای پیچیده با استفاده از عملگرهای جبری مجموعه را امکان‌پذیر می‌کند. فرآیند مدل‌سازی شامل تعریف نهادها، روابط، اقدامات، مجوزها، و در صورت نیاز، ویژگی‌ها برای سناریوهای پیشرفته‌تر مانند ABAC (کنترل دسترسی مبتنی بر ویژگی) است.

مدل سازی در Permify در مورد ایجاد یک نقشه واضح از ساختار سازمان شما و تعیین اینکه چه کسی باید چه کاری را انجام دهد است.

بیایید نحوه مدل‌سازی طرحواره در Permify را توضیح دهیم.

مرحله 1: نهادها را تعریف کنید

موجودیت ها اشیاء اصلی در مدل شما هستند. در این حالت، user ، organization ، department ، project ، file و task داریم.

 entity user {} entity organization {} entity department {} entity project {} entity file {} entity task {}

مرحله 2: ایجاد روابط

در مرحله بعد، روابط بین این موجودات را مشخص می کنیم. این نحوه اتصال آنها را مشخص می کند.

سازمان :

دارای admin کاربر است.

 entity organization { relation admin @user }

بخش :

متعلق به یک organization (والد) است.

دارای نقش های head ، manager و employee است که همه آنها کاربر هستند.

 entity department { relation parent @organization relation head @user relation manager @user relation employee @user }

پروژه :

متعلق به یک department (والدین) است.

 entity project { relation parent @department }

فایل :

متعلق به یک department (والدین) است.

owner دارد که کاربر است.

 entity file { relation parent @department relation owner @user }

وظیفه :

متعلق به یک project (والد) است.

دارای یک assignee که کاربر است.

 entity task { relation parent @project relation assignee @user }

مرحله 3: مجوزها را تعریف کنید

مجوزها تعیین می کنند که نقش های خاص چه اقداماتی را می توانند روی هر موجودیت انجام دهند.

پروژه :

مجوز contribute_to_project به employee یا manager department مادر اعطا می شود.

 entity project { // ... (existing relations) permission contribute_to_project = parent.employee or parent.manager }

فایل :

مجوزهای read ، edit و delete بر اساس manager department والد و owner کنترل می شوند.

 entity file { // ... (existing relations) permission read = parent.manager or owner permission edit = parent.manager or owner permission delete = owner }

وظیفه :

مجوز view_task به assignee داده می شود.

 entity task { // ... (existing relations) permission view_task = assignee }

طرحواره کامل:

 // Define entities entity user {} entity organization { // Organizational roles relation admin @user } entity department { // Department roles relation parent @organization relation head @user relation manager @user relation employee @user } entity project { // Project roles relation parent @department // Permissions permission contribute_to_project = parent.employee or parent.manager } entity file { // Represents files' parent entity (department) relation parent @department // Represents the owner of the file relation owner @user // Permissions permission read = parent.manager or owner permission edit = parent.manager or owner permission delete = owner } entity task { // Represents tasks' parent entity (project) relation parent @project // Represents the assignee of the task relation assignee @user // Permissions permission view_task = assignee }

تاپل های رابطه

ایجاد تاپل های رابطه برای طرحواره سازمانی را می توان از طریق Permify Playground و API انجام داد.

در اینجا نحوه ساختاربندی تاپل های رابطه بر اساس این طرح آمده است:

روابط کاربر و سازمان:

برای تخصیص یک کاربر به عنوان مدیر در یک سازمان، تاپل عبارت است از: organization:ID#admin@user:ID .

برای نشان دادن یک کاربر به عنوان عضو یک سازمان: organization:ID#member@user:ID .

روابط کاربر و بخش:

تخصیص یک رئیس به یک بخش: department:ID#head@user:ID .

انتساب مدیر به یک بخش: department:ID#manager@user:ID .

ارتباط یک کارمند با یک بخش: department:ID#employee@user:ID .

برای تنظیم سازمان اصلی یک بخش: department:ID#parent@organization:ID .

روابط پروژه و بخش:

برای تعریف بخش والد یک پروژه: project:ID#parent@department:ID .

مدیریت فایل:

مرتبط کردن یک فایل با بخش اصلی آن: file:ID#parent@department:ID .

تعریف مالک یک فایل: file:ID#owner@user:ID .

مدیریت کارها:

پیوند دادن یک کار به پروژه اصلی آن: task:ID#parent@project:ID .

تخصیص یک کاربر به عنوان واگذارنده یک کار: task:ID#assignee@user:ID .

در هر یک از این تاپل ها، ID یک مکان نگهدار است که باید با شناسه واقعی موجودیت یا کاربر در سیستم شما جایگزین شود.

به عنوان مثال، اگر سازمانی با شناسه 1 و کاربری با شناسه 3 دارید و می خواهید این کاربر را به عنوان مدیر آن سازمان اختصاص دهید، تاپل عبارت است از organization:1#admin@user:3 .

بدون عنوان
داشبورد روابط

این تاپل ها با استفاده از Permify API ایجاد و مدیریت می شوند. API امکان ایجاد، به‌روزرسانی و حذف این تاپل‌ها را در صورت نیاز فراهم می‌کند که منعکس کننده ماهیت پویای روابط و مجوزها در یک سازمان است. این انعطاف‌پذیری تضمین می‌کند که داده‌های مجوز شما همیشه به‌روز بوده و با وضعیت فعلی موجودیت‌های سیستم شما و روابط آنها سازگار است.

اجرا

برای اعمال کنترل دسترسی در طرحواره خود با استفاده از Permify، می توانید سناریوهایی را در بخش Permify Playground's Enforcement ایجاد کنید. این کار با استفاده از YAML برای تعریف سناریوهای مختلف تست انجام می شود.

در اینجا یک مثال بر اساس طرح شما و تاپل های رابطه ایجاد شده آورده شده است:

تحلیل کنید که آیا یک کاربر (به عنوان مثال: user:2) می تواند در یک پروژه مشارکت داشته باشد:

نهاد: project:1

موضوع: user:2

ادعا: contribute_to_project: true or false (بسته به اینکه کاربر:2 کارمند یا مدیر بخش اصلی پروژه:1 باشد).

 - name: user_access_test checks: - entity: project:1 subject: user:2 context: null assertions: contribute_to_project: false entity_filters: [] subject_filters: []

بررسی کنید که آیا یک کاربر (به عنوان مثال: user:4) می تواند یک کار را مشاهده کند :

موجودیت: task:1

موضوع: user:4

ادعا: view_task: true or false (در صورتی که کاربر: 4 واگذارنده کار باشد درست است).

 - name: user_access_test checks: - entity: task:1 subject: user:4 context: null assertions: view_task: false entity_filters: [] subject_filters: []

این سناریوها به شما کمک می کند مجوزها را مطابق طرح خود در یک محیط کنترل شده تأیید کنید.

هر ادعا در سناریوی YAML نتیجه مورد انتظار (درست یا نادرست) را برای یک اقدام یا مجوز خاص بر اساس طرح و تاپل های داده شما تعریف می کند.

بدون عنوان
نمایندگی YAML

برای مراحل و مثال‌های دقیق، به مستندات مدل‌سازی Permify مراجعه کنید.

نتیجه

با دنبال کردن این مراحل، می توانید به طور موثر یک سیستم ReBAC پیچیده را با استفاده از Permify پیاده سازی کنید.

این پیاده‌سازی چارچوب کنترل دسترسی قوی، انعطاف‌پذیر و ایمن را متناسب با نیازها و روابط منحصربه‌فرد درون سازمان شما فراهم می‌کند.

خبرکاو

ارسال نظر

دیدگاه‌ها بسته شده‌اند.


تبليغات ايهنا تبليغات ايهنا

تمامی حقوق مادی و معنوی این سایت متعلق به خبرکاو است و استفاده از مطالب با ذکر منبع بلامانع است