مجوزدهی (Authorization) این روزها در دنیای فناوری حسابی بر سر زبانها افتاده است. سازمانهایی مانند Apple سرمایهگذاری بیشتری روی کنترل دسترسی مبتنی بر سیاست انجام میدهند که نشانهای از حرکت به سمت «سیاست بهعنوان کد» است. با تثبیت این رویکرد، بهتدریج روشن میشود که انقلاب بزرگ بعدی در فضای مجوزدهی بر یک بخش مشخص متمرکز خواهد بود — بهطور خاص، لایه داده.
در این نقطه است که OpenFGA وارد میشود؛ یک پروژه در مرحله انکوبیشن بنیاد لینوکس (Linux Foundation) که پیرامون یک هدف واحد طراحی شده است — مقیاسپذیر، قابل پیشبینی و قابلخواندن برای انسان کردن مجوزدهی ریزدانه مبتنی بر رابطه.
در حالی که راهکارهایی مانند OAuth و OpenID Connect بر این تمرکز دارند که «کاربر چه کسی است»، OpenFGA بر این تمرکز دارد که کاربر با دادهای که به آن دسترسی دارد چه کاری میتواند انجام دهد — و اینکه در کل، چه رابطهای با سیستم دارد.
در ادامه، یک بررسی عمیق از OpenFGA انجام میدهیم و نگاه میکنیم که چه زمانی و در کجا میتواند در فضای API مفید باشد.
OpenFGA چیست؟
OpenFGA یک موتور مجوزدهی متنباز است که از سیستم Zanzibar گوگل الهام گرفته شده است. در اصل، همهچیز درباره کانتکست رابطهای است — این موتور از کنترل دسترسی مبتنی بر رابطه (Relationship-Based Access Control یا ReBAC) استفاده میکند که مجوزهای کاربر را بهطور مشخص بر اساس رابطه بین کاربر و اشیای دادهای که تلاش میکند از آنها استفاده کند تعریف میکند.
این یک تغییر بنیادین در نحوه توصیف مجوزدهی است، بنابراین ارزش دارد که کمی روی آن مکث کنیم.
مدل مجوزدهی OpenFGA حرکتی است از دستهبندی ساده به سمت وضعیت رابطهای — برای مثال، یک کاربر میتواند با یک شیء دادهای خاص رابطه داشته باشد، و رابطه بین آن شیء دادهای و سایر اشیای دادهای میتواند بر طرح مجوزدهی تأثیر بگذارد.
یک کاربر ممکن است بخواهد به یک سند دسترسی پیدا کند، و اگرچه ممکن است مجوز صریحی برای آن سند نداشته باشد، اما میتواند یک رابطه «بیننده» (viewer) با پوشه والد آن سند داشته باشد، که در نتیجه، کنترل دسترسی رابطهای برای کاربر نهایی گسترش پیدا میکند.
این موضوع نوعی منطق فازی را وارد کنترل دسترسی میکند. ناگهان، مجوزدهی کمتر بر اساس مطلقها و بیشتر بر اساس ویژگیهای رابطهای بیان میشود؛ برای مثال، «مدیرِ یک کاربر»، «مشارکتکننده در سند والد»، یا «عضو یک دپارتمان».
این روابط سپس بهصورت یک تاپل رابطهای زمینهمند (contextual relationship tuple) ذخیره میشوند:
وقتی یک کاربر تلاش میکند عملی انجام دهد یا تعاملی برقرار کند، این تاپلها میتوانند بررسی و اعتبارسنجی شوند، و همچنین در میان اشیا و سیستمها گسترش پیدا کنند، تا مشخص شود آیا کاربر مجوزهای لازم برای شیء دادهای یا سیستم موردنظر را دارد یا نه.
این رویکرد یک فاصلهگیری قابل توجه از روشهای یکپارچه و ایستای مجوزدهی است که امروزه بهطور گسترده مورد استفاده قرار میگیرند.
بهجای اینکه صرفاً یک کاربر را بهعنوان «ادمین» یا «بیننده» تعریف کنید، اکنون میتوانید دسترسی را بر اساس رابطه بین کاربر و شیء، و همچنین بین خود اشیا، واسطهگری کنید.
برای میکروسرویسهای پیچیده، APIها، و استقرارهای SaaS چندمستاجری، این موضوع پیچیدگی را بهطور قابل توجهی کاهش میدهد و تضمین میکند که مجوزدهی ریزدانه بر اساس روابط و کانتکستهای قابل مشاهده و واقعگرایانه انجام شود، نه چارچوبهای ایستا و انعطافناپذیر.
لازم به ذکر است که OpenFGA جایگزین ارائهدهنده احراز هویت و مجوزدهی شما نیست — بلکه در اساس یک مخزن رابطهای مکمل و موتور تصمیمگیری است.
با تعریف یک اسکیما برای روابط خود و ذخیره این روابط بهصورت تاپل، میتوانید بهطور فعال دسترسیها را از طریق SDKها و APIهای OpenFGA بررسی، ارزیابی و هماهنگ کنید.
OpenFGA در عمل
در عمل، این موضوع چه شکلی دارد؟ از بسیاری جهات، شبیه هر فرایند مجوزدهی دیگری است — اما تفاوت در متمرکز شدن فرایند بررسی نهفته است.
وقتی یک درخواست به یک اندپوینت میرسد، یک سرویس یک اندپوینت /check را با سه داده کلیدی فراخوانی میکند:
-
User، که همان کاربر واقعی است که درخواست را ارسال کرده است.
-
Action، که همان مجوز یا فعلی است که کاربر درخواست کرده است.
-
Object، یا منبعی که در لایه داده روی آن عملی انجام میشود.
این دادهها سپس در کانتکست تاپل ذخیرهشده بررسی میشوند — هم از نظر درخواست کاربر موردنظر و هم از نظر رابطه بین خود اشیای دادهای.
از این نقطه، OpenFGA یا یک پاسخ درست (true) یا نادرست (false) برای مجوزدهی دسترسی بازمیگرداند.
جایی که موضوع پیچیدهتر میشود، زمانی است که ارثبری، تفویض اختیار و سلسلهمراتب وارد بازی میشوند.
از آنجا که هر تاپل رابطهای میتواند رابطهای را تعریف کند که مالکیت یا دسترسی را به منابع زیرین منتقل کند، میتوان کنترلهای رابطهای بسیار پیچیدهای را در مقیاس بزرگ ایجاد کرد.
OpenFGA کجا منطقی است؟
پس این نوع رویکرد در کجا معنا پیدا میکند؟
OpenFGA در حوزههایی میدرخشد که دارای گرافهای منبع پیچیده، مجوزهای پویا، و اشیای دادهای رابطهای پیچیده هستند.
چند نمونه مناسب از چنین واقعیتهایی عبارتاند از:
-
SaaS چندمستاجری: ارائهدهندگان API با مدل SaaS ممکن است مشتریان متفاوتی با سیاستهای دسترسی بسیار پیچیده داشته باشند. در این وضعیت، گزینههای شما معمولاً یا ایجاد یک طرح مجوزدهی جداگانه برای هر سیستم است یا تحمیل یک الگوی از پیش تعریفشده توسط ارائهدهنده. با OpenFGA، میتوانید کنترلهای دسترسی تعیینشده توسط مستاجر را فراهم کنید که سپس بهشکل بسیار مؤثرتر و یکپارچهتری با مدیریت حقوق متمرکز شما تعامل دارند.
-
پلتفرمهای داده سازمانی: در چنین محیطهایی، میتوانید مجموعهدادههای سلسلهمراتبی پیچیده داشته باشید، در حالی که همچنان به مدلهای پویا و میانسازمانی برای دسترسی و مشاهده نیاز دارید. OpenFGA در اینجا کاملاً منطقی است، زیرا به شما اجازه میدهد دسترسی را بر اساس روابط با داده کنترل کنید، نه تحمیل یک راهکار «یک اندازه برای همه» بر کل سیستم داده.
در حالت ایدهآل، هر جا که به کنترلهایی مبتنی بر دسترسی رابطهای داده نیاز دارید — نه طرحهای بالا به پایین و ایستا — OpenFGA انتخاب مناسبی است.
برای مثال، خبرنامه OpenFGA اشاره میکند که virv.ai، یک پلتفرم همکاری مبتنی بر هوش مصنوعی، از OpenFGA برای ایجاد رابطه بین افراد و عاملها با مصنوعات و منابع استفاده میکند.
ابزارهای توسعهدهندهمحور دیگری مانند Grafana Labs، AppsCode و Incus نیز شروع به استفاده از OpenFGA کردهاند.
OpenFGA چگونه OAuth و OpenID Connect را تکمیل میکند
مهم است که درک کنیم این یک جایگزین مستقیم برای سایر سیستمهای مجوزدهی نیست. در واقع، در بیشتر موارد، شما میخواهید آن را با راهکارهای موجود OAuth یا OpenID Connect خود یکپارچه کنید.
این گزینههای دیگر بهطور کلی مسئول هویت و رضایت هستند — یعنی اعتبارسنجی اینکه شما همان کسی هستید که ادعا میکنید، و تأیید دسترسی شما به API یا منبع.
OpenFGA، در مقابل، مجوزدهی مرتبط با خود داده را مدیریت میکند — یک لایه الحاقی پیرامون دادهها و اشیا.
به همین دلیل، نباید آن را بهعنوان یک جایگزین یا بدیل در نظر بگیرید. یک راه خوب برای درک تفاوت این است:
-
OAuth میگوید: «بیل میتواند به API ارسالها دسترسی داشته باشد.»
-
OpenFGA میگوید: «بیل میتواند ارسالهایی را مشاهده کند که خودش آغاز کرده یا ارسالهایی که توسط افرادی مدیریت میشوند که به او گزارش میدهند.»
جمعبندی
در نهایت، مجوزدهی همیشه بخش کمزرقوبرق امنیت بوده است — تا زمانی که خراب نشود دیده نمیشود، و وقتی خراب شود، همهچیز بههم میریزد. اما با پیچیدهتر شدن سیستمها و توزیعشدن هرچه بیشتر دادههایی که روی آنها کار میکنند، باید راههایی پیدا کنیم که مجوزدهی دادهمحور را به یک دغدغه یکپارچه و سطحبالا تبدیل کنیم.
OpenFGA بخش بزرگی از این مسیر است. این ابزار یک رویکرد جدید ارائه میدهد که ترکیبپذیر، گویا، رابطهای و مبتنی بر کانتکست انسانی است. این راهکار جایگزین سایر ابزارها نمیشود، بلکه آنها را تقویت میکند تا مدیریت و کنترل بهتری فراهم شود و به سازندگان API اجازه میدهد دسترسی را بهعنوان «داده» توصیف و کنترل کنند، نه بهعنوان «کد».
