کنترل دسترسی مبتنی بر سیاست (PBAC): مروری جامع

کنترل دسترسی شکسته، خزش امتیازات و انفجار نقش، همه سازمان ها را در معرض خطر قرار می دهد. دورانی که ما فقط چند نقش در یک سازمان داشتیم گذشته است، امروز به ده ها یا حتی صدها نقش مختلف نگاه می کنیم. این نه تنها وظیفه مدیریت نقش ها را سخت تر می کند، بلکه آن سازمان ها را نیز در معرض خطر قرار می دهد.
فهرست مطالب
مدلسازی و مدیریت دسترسی کاربر در سیستمها برای امنیت، یکپارچگی و انطباق دادهها بیش از همیشه ضروری است.
امروزه مدل های کنترل دسترسی زیادی در بازار موجود است.
نمونه های معروف عبارتند از:
با این حال، در این قطعه ما بر روی PBAC مدل نیز به عنوان شناخته شده است کنترل دسترسی مبتنی بر سیاست و اینکه چگونه این مدل ها را از مدل های کنترل دسترسی سنتی از نظر مقیاس پذیری، انعطاف پذیری و امنیت متمایز می کند.
کنترل دسترسی مبتنی بر سیاست (PBAC) چیست؟
به بیان ساده، این یک روش مجوز است که دسترسی به منابع را بر اساس سیاست هایی که منعکس کننده اهداف تجاری یک سازمان است، کنترل می کند.
مدل PBAC از هر دو ویژگی و نقشها برای استخراج سیاستها استفاده میکند، بر خلاف چارچوبهای کنترل دسترسی سنتی که در آن فقط از نقشها یا ویژگیها برای استخراج حقوق دسترسی استفاده میشود. این ویژگی باعث می شود PBAC یک رویکرد واقعا قدرتمند و پویا برای کنترل پارامترها باشد.
ارائه شده توسط Policy As Code (PaC)
برخلاف بهطور سنتی که سیاستها به صورت دستی اجرا میشوند، مقیاسپذیر نیستند و فاقد چارچوبی برای اجرا هستند. مدل PBAC سیاست ها را به شیوه ای کاملا متفاوت اعمال می کند.
مدل PBAC از روشی به نام سیاست به عنوان کد (PaC) استفاده می کند، به این معنی که سیاست می تواند مستقیماً در کد نوشته شود.
از کار دستی تیم های انطباق خلاص می شود و در کد ادغام می شود و فرآیندهای خود را در طول مسیر خودکار می کند. از کنترل نسخه، بررسی و اعتبارسنجی، همه چیز از A تا Z خودکار است.
و شما آن را حدس زده اید، مزایای متعددی برای خودکار کردن مدیریت خط مشی با PaC وجود دارد، در اینجا برخی از آنها وجود دارد:
- امن تر
- به جلوگیری از خطای انسانی کمک می کند
- ممیزی راحت تر
- اجرای موارد تست بسیار ساده تر است
- بررسی و اجرای خطمشی خودکار است
- اتوماسیون = مقیاس پذیر
- باعث صرفه جویی در وقت و هزینه می شود
- سیاست را در توسعه یکپارچه می کند
- چارچوبی برای نحوه اجرای سیاست ها ارائه می دهد
توجه: یک خطمشی میتواند هر چیزی باشد که عملیات و فرآیندهای درون یک برنامه یا سازمان را با استفاده از PBAC کنترل میکند، این میتواند یک قانون، شرط یا یک دستورالعمل باشد.
تفاوت بین ABAC، RBAC، ReBAC و PBAC
برای توضیح بهتر تفاوتهای PBAC و این مدلهای رایج کنترل دسترسی، ابتدا خلاصهای از آنها را بیان میکنیم، سپس به PBAC و تمایز آن میپردازیم.
بیایید با کنترل دسترسی مبتنی بر ویژگی (ABAC) شروع کنیم.
کنترل دسترسی مبتنی بر ویژگی (ABAC)
یک مدل ABAC از ویژگی های مشتق شده از یک موضوع، منبع یا محیط استفاده می کند تا تصمیم بگیرد که آیا دسترسی به منبعی در یک سیستم اعطا می شود یا خیر.
این ویژگی ها می توانند هر مقداری باشند که این مدل را قادر می سازد سناریوهای پیچیده را مدیریت کند.
در این مدل، مجوز ریزدانهتر است، زیرا این ویژگیها میتوانند یک مقدار پویا داشته باشند که میتوانند تغییر کنند.
یک مثال که ما را قادر می سازد قوانین و رفتارهای مجوز پویا را تعریف کنیم، کنترل این است که کدام عملکرد را می توان در یک سیستم بر اساس زمان، مکان و آدرس IP کاربر انجام داد.
مدلهای ABAC میتوانند بسیار پیچیده و با خطر رفتارهای ناخواسته همراه باشند، اگر ارزشهای این ویژگیها مورد توجه و بررسی قرار نگیرند. همچنین مدیریت آن پیچیده است، یادگیری و متخصص شدن در آن بیشتر طول می کشد.
کنترل دسترسی مبتنی بر نقش (RBAC)
در یک مدل RBAC مجوزها به عنوان اقداماتی که کاربر می تواند روی یک منبع انجام دهد تعریف می شود.
سپس این مجوزها به نقشها گروهبندی میشوند و آن نقشها سپس به افراد در یک سیستم اختصاص داده میشوند. این موضوعات می توانند کاربران، گروه ها یا سیستم ها باشند.
نقش ها در این نوع مدل ایستا هستند و ترسیم نقشه و مشاهده ارتباط آنها با یکدیگر را بسیار آسان تر می کند.
مدل RBAC یک جنبه منفی دارد که انفجار نقش است.
این زمانی اتفاق میافتد که سناریوهای مجوز آنقدر زیاد باشد که تعداد زیادی نقش برای پوشش همه آنها مورد نیاز است. که کار مدیریت نقش ها را بسیار دشوارتر می کند و در برخی موارد می تواند یک نگرانی امنیتی باشد.
یکی از معایب این مدل این است که پیاده سازی آن زمان زیادی را می طلبد زیرا مدیران برای کشف هر نقش و مجوزهای آنها به زمان نیاز دارند.
کنترل دسترسی مبتنی بر رابطه (ReBAC)
همانطور که از نامش میگوید، این مدل برای کسب مجوز بر روابط متکی است.
این کار با نسبت دادن روابط بین موضوعات و منابع در یک سیستم انجام می شود. این روابط هنگام گروه بندی منابع می توانند بسیار پیچیده شوند. ReBAC یک نوع مدل “سیاست به عنوان داده” است، بر خلاف مدل های دیگر که از نوع “سیاست به عنوان کد” هستند.
این نوع مدلسازی مجوز را میتوان با مدلهای دیگر انجام داد، اما زمانی که با ReBAC انجام میشود بسیار سادهتر و مختصر است زیرا اغلب برای ساخت این نوع مدل از نمودار استفاده میشود.
همچنین یک مدل انعطافپذیر است که به ما اجازه میدهد در سطح منبع مجوز داشته باشیم و همچنین یک رابطه والد-فرزند بین موضوعات و منابع را ارائه میدهد.
کنترل دسترسی مبتنی بر سیاست (PBAC)
PBAC دارای مزایای کلیدی نسبت به چارچوبهای قدیمیتر است، دلیل اصلی آن این است که از خطمشیها برای کسب مجوز با ترکیب وظایف و خطمشیهای موضوع با استفاده از روششناسی سیاست بهعنوان کد استفاده میشود.
یکی دیگر از ویژگی های کلیدی که آن را بسیار جذاب تر از راه حل های دیگر می کند، سادگی آن در ایجاد و تست سیاست ها است. این برای اجرای ممیزی و مطابقت با قوانین سختگیرانه حفظ حریم خصوصی در حوزه های قضایی خاص عالی است.
در حالی که یک سیستم مبتنی بر نقش، دسترسی بر اساس نقشها را اعطا میکند، یک سیستم مبتنی بر سیاست، بر اساس خطمشیها دسترسی را اعطا میکند، این به ما انعطافپذیری زیادی را هنگام مدیریت مجوزهای دسترسی ارائه میدهد. مدلهای PBAC به گونهای ساخته شدهاند که با رشد سازمان از طریق اتوماسیون مقیاس شوند، یک بار بنویسند و بقیه موارد را بر عهده بگیرند.
برخلاف ABAC که در آن قوانین به زبان نشانه گذاری کنترل دسترسی توسعه پذیر (XACML) یا با استفاده از Open Policy Agent (OPA) با استفاده از زبان Rego نوشته می شود که درک آن برای افرادی که سابقه ای در زمینه فناوری اطلاعات ندارند اغلب دشوار است.
از سوی دیگر، ارائه دهندگان PBAC اجازه می دهند خط مشی ها در قالب یک زبان ساده و در برخی موارد با استفاده از رابط کاربری گرافیکی (GUI) کدگذاری شوند. اجرای سیاستهای کنترل دسترسی برای تیمهای مدیریتی با تکیه نکردن به بخش فناوری اطلاعات برای ایجاد تغییرات هرازگاهی آسانتر میشود.
در اینجا یک تصویر ساده از نحوه عملکرد یک مدل PBAC در یک محیط کاری با کارکنان آورده شده است:
تکههای اطلاعات و دادهها بلوکهای سازنده یک مدل PBAC هستند، برای تصمیمگیری برای دسترسی به آنها متکی است. با استفاده از داده های موجود، راه حلی انعطاف پذیر برای سیاست گذاری ارائه می دهد. از نظر وضوح، PBAC برنده است، به مدیران دید واضحی از اینکه چه کسی به چه چیزی، چه زمانی و چگونه در تمام دارایی های یک سازمان دسترسی دارد، می دهد.
بیایید نگاهی عمیقتر به این موضوع داشته باشیم که چه چیزی PBAC را منحصر به فرد میکند.
نقاط قوت عمده PBAC
پویا و انعطاف پذیر
مدلهای PBAC پویا هستند، به این معنی که میتوانند پارامترهای متعددی را در هنگام اعطای دسترسی و مجوز به کاربر در نظر بگیرند، که به ما امکان میدهد هنگام ایجاد قوانین خاص باشیم.
- ویژگی های کاربر (کارمند، مدیر عامل، CTO)
- ویژگی های منبع (فایل، پایگاه داده، بخش های شبکه)
- ویژگی های عمل (ورود، خواندن، نوشتن)
- ویژگی های متنی یا محیطی (موقعیت فیزیکی، دستگاه، زمان)
PBAC هنگام ارزیابی اینکه آیا دسترسی باید اعطا شود یا خیر از منطق بولی استفاده می کند، این کار را با پردازش این ویژگی ها به روش “اگر، آنگاه” انجام می دهد که با مدل های دیگر متفاوت است.
ما میتوانیم قوانینی را در یک سیستم PBAC بهصورت کاملاً خودکار اعمال کنیم و آن را با شرایط متغیر سازگار کنیم، مانند اینکه اجازه نمیدهیم کارمند در تعطیلات آخر هفته از طریق رایانه خانگی خود به سیستم دسترسی پیدا کند. این به ما کنترل بیشتری میدهد و ما را قادر میسازد تا با در نظر گرفتن زمینه، تصمیمات دسترسی را در زمان واقعی با جزئیات بالا اتخاذ کنیم.
سیستمهای مبتنی بر خطمشی ذاتاً پویا هستند و آنها را با نیازهای سازمان سازگار میسازد، خواه یک استارتآپ کوچک باشد یا یک شرکت کامل با دهها بخش.
آنها همچنین فوق العاده سریع هستند، به عنوان یک سرپرست که کنترل کاملی بر مجوزهای کاربر دارید، می توانید مجوزها را به تک تک کاربران یک سازمان با کلیک ماوس خود اضافه، حذف یا ویرایش کنید.
ایمن و قابل اعتماد
ما به عنوان انسان مستعد خطا هستیم و این در مورد مدیریت خط مشی ها و کنترل دسترسی مستثنی نیست. مدیریت خط مشی را می توان در یک سیستم PBAC خودکار کرد و نیاز انسان به بازبینی دستی خط مشی ها را از بین برد که برای امنیت عالی است.
یکی دیگر از مزایای استفاده از مدل PBAC، جداسازی امتیازات در یک سازمان است که در آن هر جزء جدا شده است تا خطر در صورت نقض امنیت به حداقل برسد. به عنوان مثال، هکری را در نظر بگیرید که یک بخش از یک شبکه را به خطر می اندازد، اگر امتیازات به طور دقیق در سراسر شبکه تنظیم شوند، به بقیه شبکه دسترسی کامل نخواهند داشت.
PBAC شکاف های امنیتی باز شده توسط RBAC را می بندد و این با فعال بودن با امنیت کنترل دسترسی انجام می شود.
سازگار و سازگار
رعایت قوانین نظارتی در حوزه های قضایی خاص امروز مهم است. سیستمهای PBAC کار را برای تیمهای انطباق برای پیروی از الزامات قانونی مربوط به حریم خصوصی دادهها و قوانین امنیتی مانند GDPR، HIPAA و CPRA بسیار آسانتر میکنند.
PBAC ما را قادر می سازد تا با تنظیم دسترسی به داده های حساس در سراسر یک سازمان یا برنامه به روشی منسجم و سیستماتیک، به راحتی سیاست های داخلی را با کنترل دسترسی هماهنگ کنیم.
موارد و مثال های استفاده از PBAC
همانطور که قبلاً گفته شد، PBAC ماهیت بسیار پویا دارد و می تواند با محیط های مختلف سازگار شود. این می تواند با رشد یک سازمان مقیاس شود، اگر یک سیاست بیان می کند که “HR می تواند به داده های کارکنان دسترسی داشته باشد”، مهم نیست که صد یا هزار کارمند وجود داشته باشد. این سیاست همچنان اعمال می شود و اجرا می شود.
بیایید نگاهی به نمونه های دنیای واقعی بیندازیم که در آن PBAC در حال عمل است:
بیایید یک مثال ساده از یک وکیل کار در یک شرکت حقوقی را ببینیم، در اینجا نحوه اعمال سیاست های کنترل دسترسی در یک سیستم PBAC برای او آمده است.
خط مشی کاربر: اجازه دسترسی به پورتال اصلی شرکت را بدهید.
سیاست منابع: اجازه دسترسی به فایل های کلاینت اختصاص داده شده به او را می دهد.
سیاست اقدام: اجازه خواندن و ویرایش فایل های مشتریان را می دهد.
سیاست محیطی و متنی: دسترسی به پورتال شرکت را در روزهای یکشنبه و شنبه مسدود کنید.
در اینجا نحوه پیاده سازی آن در پایتون با استفاده از زبان خط مشی Cedar آمده است:
from cedar.client import CedarClient
# Initialize Cedar client
cedar_client = CedarClient(api_key='YOUR_CEDAR_API_KEY_HERE', base_url='CEDAR_API_BASE_URL_HERE')
# User Policy: Allow access to the firm's main portal.
user_policy = {
'condition': {
'user': {
'role': 'employee'
},
'resource': {
'portal': 'firm'
}
},
'permission': 'allow'
}
# Resource Policy: Allow access to client files assigned to him.
resource_policy = {
'condition': {
'user': {
'role': 'employee'
},
'resource': {
'file_type': 'client'
}
},
'permission': 'allow'
}
# Action Policy: Allow permission to read and edit files of clients.
action_policy = {
'condition': {
'user': {
'role': 'employee'
},
'action': {
'read': True,
'edit': True
}
},
'permission': 'allow'
}
# Environmental and Contextual Policy: Block access to the firm's portal on Sundays and Saturdays.
contextual_policy = {
'condition': {
'day': ['Sunday', 'Saturday'],
'resource': {
'portal': 'firm'
}
},
'permission': 'deny'
}
# Add policies to Cedar
cedar_client.add_policy('user_policy', user_policy)
cedar_client.add_policy('resource_policy', resource_policy)
cedar_client.add_policy('action_policy', action_policy)
cedar_client.add_policy('contextual_policy', contextual_policy)
# Here’s how to check access for a user attempting to login into the firm's portal on a Sunday.
user_attributes = {'role': 'employee'}
resource_attributes = {'portal': 'firm'}
day = 'Sunday'
access_permission = cedar_client.check_access(user_attributes, resource_attributes, day)
print("Access permission:", access_permission)
نتیجه
چندین مدل کنترل دسترسی وجود دارد، همه با مزایا و معایب خود در مورد مدیریت مجوز.
همانطور که دیدیم، برخی از آنها برای پیاده سازی به سطح بالایی از تخصص در مدیریت کنترل دسترسی نیاز دارند، برخی دیگر نه.
در این مقاله، پیچها و مهرههای هر یک از آنها و نحوه مدیریت و استخراج قوانین کنترل دسترسی را با استفاده از ویژگیها، نقشها، روابط یا سیاستها مشاهده کردهایم.
مدل PBAC با استفاده از رویکرد سیاست بهعنوان کد برای تعریف، بهروزرسانی و اجرای سیاستها به پر کردن شکاف بین مدل RBAC و ABAC کمک میکند و بهترینهای هر دو جهان را ارائه میدهد.
این شکاف مدلهای قدیمیتر را با تسهیل مدیریت و پیشگیری و مسدود کردن درهای بالقوه منجر به آسیبپذیری پر میکند.