در یک سامانه اشتراک اسناد، پاسخ به پرسش «آیا این کاربر می تواند این فایل را ببیند؟» همیشه در یک ستون نقش کاربر پیدا نمی شود. کاربر ممکن است عضو یک گروه باشد، گروه روی پوشه دسترسی داشته باشد و فایل از همان پوشه دسترسی بگیرد. اگر این رابطه ها در ده سرویس به شکل شرط های پراکنده نوشته شوند، تغییر سیاست و پیدا کردن علت دسترسی دشوار می شود. OpenFGA برای مدل سازی و بررسی چنین رابطه هایی ساخته شده است. نقطه شروع آن جدا کردن مدل مجوز از داده رابطه ها و سپس پرسیدن یک سؤال مشخص درباره یک کاربر، رابطه و شیء است.
سه جزء یک رابطه
یک tuple رابطه ای را میان user، relation و object بیان می کند. در این زبان، user الزاماً یک انسان نیست. بسته به مدل می تواند یک موجودیت یا مجموعه کاربران حاصل از رابطه ای دیگر باشد. object نیز یک شیء دارای نوع و شناسه است. برای نمونه، «کاربر الف viewer سند گزارش» یک رابطه مستقیم است. «اعضای گروه مالی viewer سند گزارش» می تواند دسترسی را از عضویت گروه به سند پیوند دهد.
اهمیت این مدل در صریح بودن داده است. به جای اینکه یک ستون مبهم با مقدار «دسترسی ویژه» تفسیر شود، رابطه ای مشخص ثبت می شود. با این حال نام گذاری به تنهایی امنیت ایجاد نمی کند. سرویس نویسنده tuple باید مجاز باشد و ورودی آن باید کنترل شود. اگر هر کاربر بتواند خودش را owner هر سندی ثبت کند، دقیق ترین موتور بررسی نیز همان داده نادرست را مطابق مدل تفسیر خواهد کرد.
مدل مجوز با داده رابطه فرق دارد
Authorization Model تعریف می کند چه نوع موجودیت هایی وجود دارند و هر رابطه چگونه به دست می آید. داده tuple می گوید در وضعیت فعلی چه رابطه هایی برقرار هستند. این جدایی شبیه تفاوت طرح و رکورد در یک پایگاه داده است، اما معنای محاسبه رابطه در مدل نقش مهمی دارد. برای مثال viewer ممکن است از رابطه مستقیم یا از editor به دست آید. در این صورت لازم نیست برای هر ویرایشگر یک رکورد تکراری viewer نیز ثبت شود.
مدل باید از قواعد واقعی محصول شروع شود. اگر مالک می تواند ویرایش کند و ویرایشگر می تواند بخواند، این وراثت باید روشن باشد. اگر برخی اسناد محرمانه از دسترسی پوشه ارث نمی برند، این استثنا نباید فقط در یک سرویس فرانت اند پنهان بماند. نوشتن چند مثال مثبت و منفی پیش از ساخت مدل کمک می کند معلوم شود آیا مدل دامنه کسب و کار را درست بیان می کند یا صرفاً ساختار جدول های موجود را تقلید کرده است.
Check دقیقاً چه سؤالی می پرسد؟
درخواست Check معمولاً می پرسد آیا یک user رابطه مشخصی با یک object دارد یا نه. پاسخ به مدل انتخاب شده و رابطه های موجود وابسته است. برنامه باید نوع و شناسه شیء را از منبع قابل اعتماد بسازد. گرفتن نام شیء از پارامتر دلخواه کاربر بدون بررسی ارتباط آن با درخواست تجاری می تواند باعث بررسی مجوز برای یک شیء و انجام عملیات روی شیئی دیگر شود.
برای مثال، اگر مسیر HTTP شناسه سند را می گیرد اما برنامه مجوز پوشه را با یک شناسه جداگانه از بدنه بررسی می کند، امکان ناهماهنگی وجود دارد. بهتر است شیء هدف از داده واقعی سند استخراج شود و همان شناسه در بررسی و عملیات استفاده شود. همچنین نتیجه Check باید در نقطه اجرای عملیات رعایت شود. نمایش ندادن دکمه ویرایش در رابط کاربری، جای کنترل در API را نمی گیرد. هر مسیر جایگزین مانند کار پس زمینه یا دریافت فایل نیز باید این قرارداد را داشته باشد.
گروه ها و مجموعه کاربران
استفاده از گروه ها هزینه تغییر اعضا را کاهش می دهد. اگر صد سند به گروه مالی متصل باشند، خروج یک نفر از آن گروه می تواند دسترسی حاصل از عضویت را تغییر دهد، بدون اینکه صد رابطه مستقیم فردی حذف شود. اما مدل باید روشن کند آیا گروه ها می توانند عضو گروه های دیگر باشند و اگر چنین است، عمق و پیچیدگی رابطه ها چگونه کنترل می شود. سلسله مراتب نامنظم می تواند توضیح علت یک دسترسی را دشوار کند.
در طراحی عملی، برای هر گروه باید مالک و منبع معتبر عضویت مشخص باشد. اگر سامانه منابع انسانی و مدیر محلی محصول هر دو عضویت را تغییر می دهند، قواعد تعارض لازم است. داده ای که دیر از منبع بیرونی همگام می شود ممکن است کاربر خارج شده را همچنان عضو نشان دهد. OpenFGA تصمیم را بر اساس داده قابل دسترس می گیرد؛ تازگی داده عضویت مسئولیتی مشترک میان سامانه هویت، مسیر همگام سازی و برنامه مصرف کننده است.
پوشه، سند و دسترسی ارثی
یک الگوی متداول این است که سند رابطه parent با پوشه داشته باشد و viewer سند از viewer پوشه نیز مشتق شود. این الگو ساختار اشتراک فایل را طبیعی تر می کند. با این حال انتقال سند به پوشه دیگر فقط تغییر محل نمایش نیست. این جابه جایی می تواند مجموعه کاربران دارای دسترسی را عوض کند. بنابراین عملیات انتقال باید هم از نظر مجوز انجام جابه جایی و هم از نظر اثر آن بر دسترسی نهایی بررسی شود.
برای سند حساس، می توان پیش از انتقال مجموعه نمونه ای از کاربران را بررسی کرد و پس از انتقال نیز آزمون منفی انجام داد. مهم است که حذف رابطه parent قدیمی و افزودن رابطه جدید با مدل سازگاری سامانه هماهنگ باشد. اگر داده اصلی و داده مجوز در دو ذخیره ساز متفاوت هستند، شکست میانی باید راه ترمیم داشته باشد. یک کار تطبیق دوره ای می تواند اسناد دارای رابطه نامعتبر یا گمشده را پیدا کند، اما نباید جای طراحی درست مسیر نوشتن را بگیرد.
احراز هویت و مجوز دو پرسش جدا هستند
OpenFGA درباره رابطه ها تصمیم می گیرد. اینکه درخواست واقعاً از چه شخص یا سرویسی آمده، باید در لایه احراز هویت تعیین شود. شناسه user نباید صرفاً از یک فیلد قابل تغییر در درخواست عمومی پذیرفته شود. برنامه پس از اعتبارسنجی نشست یا توکن، شناسه داخلی مناسب را به بررسی مجوز می فرستد. نگاشت میان شناسه سامانه هویت و شناسه موجود در tupleها باید پایدار و قابل حسابرسی باشد.
تغییر ایمیل نمونه خوبی از این مسئله است. اگر ایمیل شناسه اصلی رابطه ها باشد، تغییر آدرس یا واگذاری دوباره آن می تواند رفتار نامطلوبی ایجاد کند. استفاده از شناسه داخلی پایدار معمولاً تحلیل چرخه عمر را ساده تر می کند. برای حساب های سرویس نیز باید معلوم باشد مالک، هدف و زمان انقضای اعتبار چیست. یک رابطه قدیمی که به حساب رهاشده اشاره می کند ممکن است سال ها بعد دوباره اهمیت امنیتی پیدا کند.
سازگاری پس از تغییر دسترسی
کاربر انتظار دارد پس از لغو دسترسی، نتیجه بررسی بعدی آن را منعکس کند. در سامانه توزیع شده، cache و شیوه خواندن داده بر این انتظار اثر می گذارند. OpenFGA گزینه های مرتبط با consistency دارد و باید رفتار آن ها در نسخه و استقرار مورد استفاده بررسی شود. انتخاب تأخیر کمتر یا تازگی بیشتر داده یک تصمیم عملیاتی است که برای همه عملیات الزاماً یکسان نیست.
در سناریوی اشتراک فوری سند، می توان پس از ثبت رابطه جدید، بررسی را با سیاست مناسب تازگی انجام داد تا کاربر با نتیجه قدیمی روبه رو نشود. برای لغو دسترسی حساس نیز باید کل مسیر را دید. اگر فایل قبلاً در یک CDN عمومی cache شده یا لینک امضاشده بلندمدت صادر شده باشد، تغییر tuple به تنهایی آن دسترسی مستقل را پس نمی گیرد. سیاست مجوز باید با طول عمر لینک، cache پاسخ و کنترل ذخیره سازی هماهنگ باشد.
فهرست اشیا با بررسی یک شیء متفاوت است
نمایش فهرست اسنادی که کاربر می تواند ببیند، مسئله ای متفاوت از Check یک سند مشخص است. APIهای فهرست و روش ترکیب آن ها با جست وجوی داده باید با حجم و الگوی دسترسی سنجیده شوند. گرفتن هزاران سند از پایگاه داده و اجرای یک درخواست جداگانه برای هر کدام ممکن است تأخیر زیادی بسازد. از طرف دیگر، اعتماد به یک فهرست قدیمی بدون بررسی نهایی برای عملیات حساس می تواند ریسک ایجاد کند.
راه مناسب به اندازه داده و نیاز محصول وابسته است. می توان جست وجو را محدود کرد، نتایج را صفحه بندی کرد و مسیر بررسی نهایی را در API نگه داشت. باید مراقب بود تعداد نتیجه و زمان پاسخ نیز اطلاعات ناخواسته درباره اسناد غیرمجاز ندهد. برای آزمون عملکرد، فقط کاربری با ده سند کافی نیست. کاربری با عضویت های متعدد و هزاران رابطه می تواند مسیر محاسبه بسیار متفاوتی ایجاد کند.
مدل جدید را با مجموعه آزمون منتشر کنید
تغییر مدل می تواند دسترسی افراد زیادی را عوض کند، حتی اگر هیچ tuple تازه ای نوشته نشود. بنابراین مدل مجوز باید نسخه دار، بازبینی شده و همراه آزمون باشد. برای هر سناریوی مهم، چند پاسخ مورد انتظار تعریف کنید. مالک باید بتواند ویرایش کند، خواننده نباید حذف کند، عضو خارج شده گروه نباید دسترسی ارثی داشته باشد و کاربر یک سازمان نباید به اسناد سازمان دیگر دسترسی پیدا کند.
آزمون های منفی اغلب از مثال های مثبت مهم ترند. یک مدل بسیار باز می تواند همه مثال های مجاز را قبول کند و همچنان ناامن باشد. قبل از تغییر مدل فعال، اجرای همان درخواست های نمونه روی مدل قبلی و جدید می تواند اختلاف ها را آشکار کند. هر اختلاف باید توضیح تجاری داشته باشد. انتخاب شناسه مدل در مصرف کننده ها نیز باید کنترل شود تا بخشی از سرویس ها به طور ناخواسته با قواعد متفاوت تصمیم نگیرند.
مشاهده پذیری بدون افشای داده
برای رسیدگی به شکایت «من فایل را نمی بینم»، باید بتوان شناسه درخواست، مدل مورد استفاده، نوع رابطه و نتیجه بررسی را دنبال کرد. ثبت همه tupleها یا نام فایل های حساس در لاگ عمومی راه مناسبی نیست. داده مشاهده پذیری باید برای تشخیص کافی باشد و همزمان دسترسی و مدت نگهداری محدود داشته باشد. شناسه های فنی و کدهای خطای ساختاریافته اغلب از متن آزاد پر از اطلاعات شخصی مفیدترند.
خطای ارتباط با سرویس مجوز نیز باید از پاسخ منفی واقعی جدا شود. پاسخ «دسترسی ندارد» با «بررسی انجام نشد» معنای یکسانی ندارد. برنامه باید سیاست شکست روشن داشته باشد و عملیات حساس را بر پایه یک فرض خوش بینانه ادامه ندهد. برای تجربه کاربر می توان پیام مناسب و امکان تلاش دوباره فراهم کرد، اما نباید اختلال زیرساختی را به مجوز دائمی تبدیل کرد.
یک آزمایش کوچک برای اعتماد به مدل
یک محیط آزمایشی با دو سازمان، دو گروه، چند پوشه و چند سند بسازید. دسترسی مستقیم، ارثی، لغوشده و انتقال سند را جدا آزمایش کنید. سپس یکی از سرویس های مصرف کننده را با مدل قبلی نگه دارید تا خطر ناسازگاری نسخه آشکار شود. در مرحله دیگر، تأخیر همگام سازی عضویت را شبیه سازی کنید و ببینید چه مدت طول می کشد تا تغییر در نتیجه واقعی کاربر دیده شود.
معیار موفقیت این است که هر دسترسی توضیح روشنی داشته باشد و هر منع نیز قابل فهم باشد. OpenFGA زمانی ارزش بیشتری ایجاد می کند که منطق رابطه ها را از شرط های پراکنده بیرون بیاورد، اما مالکیت داده، کنترل مسیر نوشتن و اجرای تصمیم همچنان صریح باقی بماند. موتور مجوز بخش مهمی از معماری است، نه جایگزین تمام مرزهای امنیتی برنامه.
