‍ نگاهی به OpenFGA؛ سیستم مجوزدهی گراف‌محور الهام‌گرفته از Google Zanzibar

در یکی از پروژه‌های اخیر مشاوره، در حال راه‌اندازی و تست زیرساخت یک Lakehouse با استفاده از LakeKeeper بودم — یک کاتالوگ سرور سبک برای Iceberg.

برای احراز هویت و کنترل دسترسی، این سیستم از ترکیب Keycloak و OpenFGA استفاده می‌کند.

کتابخانه #Keycloak را قبلاً می‌شناختم، اما #OpenFGA برایم جدید بود و کنجکاوم کرد. این پست خلاصه‌ای از بررسی اولیه‌ام درباره‌ی این ابزار مدرن مجوزدهی است.

🧠 نقطه‌ی آغاز: Google Zanzibar

در سال ۲۰۱۹، گوگل مقاله‌ای منتشر کرد با عنوان:

“Zanzibar: Google’s Consistent, Global Authorization System”

این مقاله مدل جدیدی برای مدیریت مجوزهای دسترسی در سیستم‌های بزرگ معرفی کرد؛ مدلی که بر پایه‌ی روابط گرافی میان کاربران، گروه‌ها و منابع طراحی شده بود. این مدل، به نام #ReBAC (Relationship-Based Access Control) شناخته می‌شود.

کتابخانه OpenFGA یکی از معروف‌ترین پیاده‌سازی‌های متن‌باز بر اساس این مدل است.


🔄 مدل ReBAC در برابر RBAC و ABAC

در سیستم‌های سنتی، ما با دو مدل رایج کار می‌کردیم:

مدل #RBAC می‌پرسد: «چه کسی هستید؟» (مثلاً: مدیر / کاربر)

مدل #ABAC می‌پرسد: «چه ویژگی‌هایی - Attribute -دارید؟» (مثلاً: دپارتمان = منابع انسانی)

اما در دنیای واقعی، سناریوهای پیچیده‌تری وجود دارد:

«کاربری می‌تواند گزارش پروژه را ببیند، اگر عضو تیم فنی باشد، پروژه به او تخصیص داده شده باشد، و حساب او تعلیق نشده باشد.»

در این‌جا مدل ReBAC وارد می‌شود:

"چه رابطه‌ای با منبع دارید؟"



🔄کتابخانه OpenFGA چیست؟

پروژه OpenFGA یکی از پیاده‌سازی‌های متن‌باز، سریع و قابل‌اتکای مدل #ReBAC است که با زبان #Go توسعه یافته است.

این ابزار که توسط تیم Auth0 و Okta توسعه یافته، به شما امکان می‌دهد:

- دسترسی‌ها را در قالب گرافی از روابط بین کاربران، گروه‌ها و منابع مدل کنید

- منطق مجوزدهی را از کد جدا نگه دارید و از طریق API فراخوانی کنید

- با ابزارهای احراز هویت مانند Keycloak یا OIDC ادغام کنید

- شرط‌های پیچیده را اعمال کنید (مثلاً: دسترسی فقط اگر حساب کاربر فعال باشد)

✅ چه پروژه‌ها و شرکت‌هایی از این مدل استفاده می‌کنند؟

- نتفلیکس از پروژه‌ی مشابهی به نام SpiceDB (محصول AuthZed) استفاده کرده و آن را توسعه داده تا ویژگی‌های ABAC را نیز پشتیبانی کند.

- شرکت Airbnb سیستم داخلی خود به نام Himeji را بر پایه همین ایده ساخته است.

- پروژه OpenObserve یک کتابخانه مدیریت observability است که OpenFGA را مستقیماً به‌کار گرفته.

- پروژه Backstage (Spotify) امکان اتصال به OpenFGA از طریق پلاگین‌های متن‌باز را دارد.

- و ...


🔄 آیا فقط OpenFGA؟ نه الزاماً!

مقاله Google Zanzibar الهام‌بخش چندین پروژه متن‌باز دیگر نیز شده است که می‌توانید به‌جای OpenFGA از آن‌ها استفاده کنید.

مثلاً: Permify یک سیستم متن‌باز برای مجوزدهی ریزدانه (Fine-Grained Authorization) که کاملاً از مدل #Zanzibar پیروی می‌کند.

همچنین می‌توان به Ory Keto و SpiceDB نیز اشاره کرد که در زمینه مشابه فعال‌اند.

📌 جمع‌بندی

اگر در حال طراحی یک زیرساخت داده‌محور، داشبورد چندمستأجری، پلتفرم SaaS یا سامانه‌ی مشارکتی هستید، و مدل #RBAC دیگر جواب نیازهایتان را نمی‌دهد، حتماً نگاهی به #OpenFGA و سایر پروژه‌های مبتنی بر #ReBAC داشته باشید: به عنوان یک روش قابل اطمینان برای مدیریت دسترسی در مقیاس بالا و مناسب کاربردهای پیچیده مجوزدهی.

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.

این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.

📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.

🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨


⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!

✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.

✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.

✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.

✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.

✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.

این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.

همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪

🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶

🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت

🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg

🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها

🔰سازگاری کامل با #Lakekeeper REST Catalog

🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch

🔰حالت Memory-Only برای پردازش‌های فوق‌سریع


🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با

#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks

را گام‌به‌گام بررسی می‌کنیم. 🚀

به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،

و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟