ایزولاسیون داده‌های چند شرکتی با Supabase و PostgreSQL RLS

مقدمه و رویکرد معماری

در معماری‌های نرم‌افزاری چند شرکتی (Multi-tenant)، جداسازی امن داده‌های مشتریان مختلف در یک پایگاه داده یکسان، یک نیاز حیاتی است. به منظور حفاظت از داده‌های کسب‌وکارها و تضمین انطباق قانونی، مکانیزم‌های امنیتی در سطح سطر (Row-level) به کار گرفته می‌شوند. در همین راستا، زیرساخت‌های امن با استفاده از فناوری‌های لینوکس، داکر، Nginx، PostgreSQL و میزبان‌محور (Self-hosting) Supabase در چارچوب زیرساخت سرور و ابری مدیریت می‌شوند.

اصول پایه PostgreSQL RLS

قابلیت امنیت در سطح سطر (Row Level Security - RLS) که توسط زیرساخت PostgreSQL ارائه می‌شود، به شما امکان می‌دهد دسترسی به داده‌های درون جداول را در سطح هر سطر فیلتر کنید. در حالی که روش‌های مجوزدهی استاندارد معمولاً در سطح جدول باقی می‌مانند، به لطف مکانیزم RLS، ساختارهای تننت مختلف که از یک جدول مشترک استفاده می‌کنند، تنها می‌توانند داده‌های مربوط به خود را مشاهده کنند.

• به جای امنیت در سطح جدول، فیلترگذاری در سطح سطر اعمال می‌شود.
• پرس‌وجوهای SQL به طور خودکار با فیلتر شرکت مربوطه اجرا می‌شوند.
• خطرات احتمالی نشت داده در لایه اپلیکیشن، در سطح پایگاه داده مسدود می‌شوند.

پیکربندی ایزولاسیون تننت روی Supabase

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

مراحل تعریف سیاست (Policy)

1. فعال‌سازی قابلیت RLS در جدول مورد نظر.
2. نوشتن توابع PostgreSQL که هویت شرکتی کاربر را تأیید می‌کنند.
3. ایجاد سیاست‌های مناسب (Policies) برای عملیات‌های SELECT، INSERT، UPDATE و DELETE.

ارزیابی عملکرد و امنیت

استفاده از RLS در سیستم‌های چند شرکتی باید با استراتژی‌های ایندکس‌گذاری صحیح پشتیبانی شود. تعریف ایندکس‌های مناسب B-tree روی ستون‌های شناسه شرکت (Tenant ID)، از تأثیر منفی سیاست‌های امنیتی بر عملکرد پرس‌وجوها جلوگیری می‌کند. بهینه‌سازی‌های زیرساخت و فرآیندهای مدیریت پایگاه داده، پایداری سیستم را به طور مستقیم تحت تأثیر قرار می‌دهند.

سناریوی فرضی و نمونه پیاده‌سازی

برای ملموس‌تر کردن این رویکرد، سناریوی فرضی را در نظر بگیریم که در آن دو شرکت مختلف (شرکت الف و شرکت ب) از یک نرم‌افزار صورت‌حساب‌نویسی یکسان استفاده می‌کنند. جدول faturalar شامل ستون sirket_id برای هر رکورد است. هنگامی که کاربران از طریق Supabase وارد سیستم می‌شوند، هویت شرکتی خود را از طریق فیلد app_metadata در توکن JWT به نشست پایگاه داده منتقل می‌کنند. وقتی مدیر مالی شرکت الف به سیستم متصل می‌شود، سیاست RLS تعریف شده روی PostgreSQL به طور خودکار فعال شده و فیلتر WHERE sirket_id = current_setting('request.jwt.claim.sirket_id', true) را به تمام پرس‌وجوهای SELECT اضافه می‌کند. به این ترتیب، مهم نیست کاربر چه نوع فیلتری در رابط کاربری اعمال کند، حتی اگر به صورت فیزیکی صورت‌حسابی متعلق به شرکت ب را جستجو کند، لایه پایگاه داده نتیجه خالی یا خطا برمی‌گرداند. این وضعیت حتی در صورت وجود آسیب‌پذیری احتمالی در لایه اپلیکیشن نیز از نشت داده‌ها جلوگیری می‌کند. با این حال، مبادله اصلی که در اینجا باید به آن توجه شود، افزایش جزئی بار پایگاه داده و ضرورت تنظیم کانتکست در هر پرس‌وجو است. یک ساختار JWT پیکربندی شده به اشتباه می‌تواند باعث شود کاربران به هیچ داده‌ای دسترسی پیدا نکنند یا وارد کانتکست تننت اشتباهی شوند. در چنین سناریوهای خطایی، با استفاده از لاگ‌های پایگاه داده و مکانیزم‌های مدیریت خطای Supabase، کمبودهای کانتکست نشست باید به سرعت شناسایی شده و کاربر به طور امن به صفحه خروج هدایت شود.

چک‌لیست دقیق پیاده‌سازی و امنیت

مراحلی که باید پیش از انتقال یک پروژه چند شرکتی Supabase و PostgreSQL RLS به محیط عملیاتی (Live) به طور کامل اجرا شوند عبارتند از:

• فعال‌سازی RLS: باید اطمینان حاصل شود که دستور ALTER TABLE tablo_adi ENABLE ROW LEVEL SECURITY; در تمامی جدول حاوی داده‌های حساس اجرا شده است.
• استراتژی ایندکس‌گذاری: برای جلوگیری از افت عملکرد، باید ایندکس‌های B-tree روی ستون sirket_id در هر جدول تعریف شده و با برنامه‌های پرس‌وجو (EXPLAIN ANALYZE) تأیید شوند.
• محدوده سیاست: برای هر نوع عملیات (SELECT، INSERT، UPDATE، DELETE) باید سیاست‌های جداگانه‌ای نوشته شود و به‌ویژه در عملیات‌های INSERT بررسی شود که شرایط WITH CHECK فراموش نشده باشند.
• یکپارچه‌سازی JWT: باید تست شود که ساختار توکن دریافتی از سرویس احراز هویت Supabase به درستی توسط توابع پایگاه داده خوانده شده و توکن‌های غیرمجاز رد می‌شوند.
• مدیریت خطا و استثنائات: در صورت عدم یافتن کانتکست تننت (مثلاً برای کاربران ناشناس یا در صورت وجود توکن‌های ناقص)، باید اطمینان حاصل شود که سیستم به جای کرش کردن، دسترسی را به طور امن رد می‌کند.
• تضمین زیرساخت: به روزرسانی‌های امنیتی پیکربندی‌های کانتینر داکر و PostgreSQL باید به طور منظم مطابق با استانداردهای زیرساخت سرور و ابری انجام شود.

منابع

• زیرساخت سرور و ابری — Cy Logic Software