راهنمای اجرای مجوز ریزدانه

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

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

برای نشان دادن تمایز بین احراز هویت و مجوز، اغلب از مثال بردن خانواده شما به دیزنی لند استفاده می‌کنم. احراز هویت مانند گیت جلویی است که در آن هنگام ورود، بلیط و شناسه خود را به دروازه‌بان نشان می‌دهید و بررسی می‌کند که شما همان کسی هستید که می‌گویید هستید – دقیقاً مانند زمانی که وارد برنامه‌ای می‌شوید که در آن سیستم احراز هویت نام کاربری و رمز عبور شما را بررسی می‌کند. هویت خود را تأیید کنید.

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

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

RBAC و ABAC

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

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

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

ReBAC وارد گپ می‌شود

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

به‌عنوان مثال، یک بیمارستان معمولی را در نظر بگیرید که دارای طیف وسیعی از افراد و وظایف است – از مدیران بیمارستان، پزشکان و پرستاران گرفته تا تکنسین‌های آزمایشگاه، نگهبانان امنیتی و سرایدار. در حالی که ممکن است به همه این افراد اجازه دسترسی به درب ورودی داده شود، این بدان معنا نیست که همه آنها از حقوق مجوز یکسانی برخوردارند. علاوه بر این، فقط به این دلیل که ممکن است یک پزشک صلاحیت بررسی سوابق دقیق بیمار را داشته باشد، لزوماً به این معنی نیست که آنها باید به اطلاعات ممتاز هر بیمار دسترسی داشته باشند – فقط به آنهایی که تحت مراقبت او هستند در حالی که مؤسسه مراقبت از آنها ارائه می‌کند.< /p>

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

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

دستورالعمل‌های پیاده‌سازی ReBAC

پیاده‌سازی و مدیریت یک سیستم ReBAC می‌تواند کاری پیچیده باشد، به‌ویژه در سازمان‌های بزرگی که روابط و وابستگی‌های متقابل متعدد هستند و دائماً در حال تغییر هستند. اگر می‌خواهید ReBAC را پیاده‌سازی کنید، این سه دستورالعمل را در نظر بگیرید.

روی تعریف اولیه تمرکز کنید

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

برای تضمین بردهای سریع از کوچک شروع کنید

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

توسعه، آزمایش، و اصلاح خط‌مشی‌ها

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

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

ریشی بهارگاوا یکی از بنیانگذاران Descope، یک پلتفرم احراز هویت و مدیریت هویت مشتری را بکشید و رها کنید.

—

New Tech Forum مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.