AuthZEN چیست؟

AuthZEN: مجوزدهی مبتنی بر استاندارد برای درگاه‌های API

درگاه‌های API مدت‌هاست نقش کلیدی در ایمن‌سازی دسترسی به API ایفا می‌کنند و وظایفی مانند احراز هویت، مجوزدهی و مدیریت ترافیک را بر عهده دارند. با این حال، مجوزدهی عمیق‌تر اغلب به پیاده‌سازی‌های سفارشی یا واگذاری به منطق اختصاصی هر سرویس نیاز داشته است و این موضوع باعث ناهماهنگی‌ها و سربار عملیاتی می‌شود. راهکارهای اختصاصی یا غیراستاندارد معمولاً باعث می‌شوند درگاه API هم‌زمان به‌عنوان نقطه تصمیم‌گیری سیاست‌ها (PDP) و نقطه اعمال سیاست‌ها (PEP) عمل کند و کنترل دسترسی به‌طور تنگاتنگی در خود درگاه گره بخورد.

چند سال پیش با تعبیه Open Policy Agent ‏(OPA) به‌عنوان یک افزونه در میان‌افزار درگاه API به این موضوع پرداختم. این رویکرد PDP را از PEP جدا کرد و امکان ارزیابی سیاست‌ها را به‌شکلی منعطف‌تر و مقیاس‌پذیرتر فراهم ساخت. با این حال، با وجود بهبود انعطاف‌پذیری، همچنان یک راهکار سفارشی بود که قابلیت تعامل‌پذیری نداشت. آیا می‌توان بهتر از این عمل کرد؟

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

نیاز به مجوزدهی با دانه‌بندی متوسط

مجوزدهی را می‌توان در سه سطح دسته‌بندی کرد:

مجوزدهی با دانه‌بندی درشت – این نوع دسترسی را در سطحی کلی کنترل می‌کند، مانند کل برنامه‌ها یا عملکردهای اصلی سیستم. کنترل دسترسی مبتنی بر نقش (RBAC) معمولاً در این دسته قرار می‌گیرد، جایی که به کاربران بر اساس نقش‌ها مجوز داده می‌شود؛ برای مثال، آیا یک مدیر می‌تواند به داشبورد مدیریتی دسترسی داشته باشد؟

مجوزدهی با دانه‌بندی متوسط – این سطح کنترل دسترسی را در سطح API اعمال می‌کند و مشخص می‌سازد آیا یک کاربر می‌تواند به یک نقطه پایانی مشخص بر اساس ویژگی‌هایی مانند نقش‌ها، روش‌های درخواست یا شرایط دیگر دسترسی داشته باشد یا خیر. برای مثال: آیا این کاربر می‌تواند یک درخواست GET روی ‎/transactions‎ انجام دهد؟ کنترل دسترسی مبتنی بر ویژگی (ABAC) اغلب در این دسته قرار می‌گیرد و قوانین منعطف‌تری نسبت به RBAC فراهم می‌کند.

مجوزدهی با دانه‌بندی ریز (کنترل در سطح فیلد و شیء) – این سطح بسیار عمیق‌تر عمل می‌کند و دسترسی به فیلدهای داده یا اشیای خاص در پاسخ API را کنترل می‌کند. برای مثال:
• یک کاربر فقط می‌تواند ۴ رقم آخر شماره حساب بانکی را ببیند

• یک تحلیل‌گر می‌تواند موجودی‌ها را مشاهده کند، اما اجازه ویرایش ندارد

• یک مشتری فقط می‌تواند به فاکتورهای خودش دسترسی داشته باشد، نه فاکتورهای دیگران

این سطح از اعمال سیاست‌ها معمولاً در منطق برنامه یا پایگاه‌های داده انجام می‌شود. مهم‌ترین آسیب‌پذیری در این سطح، مجوزدهی شکسته در سطح شیء (BOLA) است که در فهرست ۱۰ آسیب‌پذیری برتر امنیت API در OWASP دیده می‌شود.

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

دفاع در عمق – راهبردی لایه‌ای برای امنیت API

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

یک مدل امنیتی قدرتمند به یک لایه حفاظتی متکی نیست. در عوض، اتخاذ راهبرد دفاع در عمق تضمین می‌کند که اگر یک لایه دور زده شود، کنترل‌های دیگری برای جلوگیری از دسترسی غیرمجاز وجود داشته باشد و دامنه آسیب محدود بماند.

در این رویکرد، درگاه API به‌صورت متمرکز احراز هویت و کنترل دسترسی را اعمال می‌کند. همچنین محدودسازی نرخ و کنترل ترافیک را انجام می‌دهد و از حملات منع سرویس (DoS) یا حملات بروت‌فورس جلوگیری می‌کند؛ علاوه بر این، مسئول تشخیص تهدید و ثبت لاگ‌ها نیز هست. برخی درگاه‌های API مانند Tyk می‌توانند اعتبارسنجی درخواست و ورودی‌های مبتنی بر شِما را بر اساس OpenAPI Schema انجام دهند.

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

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

درک AuthZEN

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

به خاطر دارید که اشاره کردم قبلاً روی یک افزونه OPA کار کرده بودم؟ دقیقاً منظورم همین بود که آن راهکار سفارشی بود و تعامل‌پذیری نداشت.

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

چرا استانداردسازی مجوزدهی اهمیت دارد

اُمری گازیت، هم‌رییس کارگروه AuthZEN در OpenID، یک مشکل بنیادین در حوزه مجوزدهی را به‌عنوان چالش «N * M» توصیف می‌کند. هر برنامه روش خاص خود را برای تخصیص مجوزها به کاربران دارد و توسعه‌دهندگان را مجبور می‌کند برای هر سیستم، یک یکپارچه‌سازی سفارشی ایجاد کنند. این پراکندگی ناکارآمد و پرهزینه است.

همان‌طور که OpenID Connect احراز هویت را استاندارد کرد و نیاز به یکپارچه‌سازی‌های سفارشی ورود را از بین برد، AuthZEN نیز قصد دارد همین کار را برای مجوزدهی انجام دهد. با تعریف یک API مشترک برای ارتباط نقاط اعمال سیاست (PEP) با نقاط تصمیم‌گیری سیاست (PDP)، AuthZEN مسئله را از «N * M» (هر برنامه با هر ارائه‌دهنده مجوزدهی) به «N + M» (یک‌بار یکپارچه‌سازی برنامه‌ها با یک API استاندارد) تبدیل می‌کند.

این استانداردسازی برای همه مزایا دارد:

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

برای جزئیات کامل آخرین پیش‌نویس کاری AuthZEN، مشخصات مربوطه در وب‌سایت OpenID Foundation در دسترس است.

نحوه کار افزونه

وقتی یک درخواست توسط درگاه API دریافت می‌شود:

• درگاه جزئیات مرتبط با درخواست مانند هویت کاربر، روش درخواست و منبع در حال دسترسی را استخراج می‌کند.
• این جزئیات در قالب یک درخواست استاندارد AuthZEN قالب‌بندی می‌شوند.
• درخواست به یک PDP سازگار ارسال می‌شود (مانند Aserto، OPA، Cerbos، Axiomatics، Topaz و دیگران).
• PDP درخواست را بر اساس سیاست‌های از پیش تعریف‌شده ارزیابی کرده و تصمیم اجازه یا عدم اجازه را بازمی‌گرداند.
• درگاه بسته به پاسخ، درخواست را به بک‌اند ارسال می‌کند یا آن را مسدود می‌سازد.

اگر علاقه‌مند به مشاهده افزونه در عمل یا استفاده از آن هستید، می‌توانید از طریق مخزن AuthZEN در بنیاد OpenID به آن دسترسی داشته باشید؛ این مخزن شامل یک ابزار سازگاری، یک فرانت‌اند TODO با تم Rick and Morty، بک‌اند، PDPهای سازگار با AuthZEN و پیاده‌سازی‌های درگاه است.

نتیجه‌گیری

درگاه‌های API بهترین مکان برای اعمال مجوزدهی با دانه‌بندی متوسط هستند و کنترل دسترسی ایمن و کارآمد را تضمین می‌کنند.

با بهره‌گیری از یک PDP منطبق با AuthZEN، سازمان‌ها می‌توانند APIهای مقیاس‌پذیر و امن بسازند، بدون آنکه منطق تصمیم‌گیری پیچیده را در ریزسرویس‌ها تعبیه کنند، منطق بیش از حدی را در درگاه API قرار دهند یا به یک ارائه‌دهنده مجوزدهی خاص وابسته شوند.

استفاده از AuthZEN اعمال سیاست‌ها را با ارائه یک چارچوب استاندارد برای ارتباط با PDPهای مختلف ساده می‌کند. این رویکرد کنترل دسترسی یکپارچه‌ای را در تمام APIها تضمین می‌کند، سربار عملیاتی را کاهش می‌دهد و در عین حال انعطاف‌پذیری و تعامل‌پذیری را حفظ می‌کند.