ایзоلاسیون داده‌های بین شرکتی و معماری Tenant در طراحی پایگاه داده ERP

هنگام توسعه نرم‌افزار سازمانی سفارشی برای ساختارهای هلدینگی یا شرکت‌های گروهی که میزبان چندین شخصیت حقوقی هستند، تصمیمات معماری حیاتی شامل استراتژی‌های امنیت داده و ایزولاسیون می‌شود. در فرآیندهای Kurumsal Yazılım & ERP، باید مدل مناسبی برای جلوگیری از نشت داده‌های بین شرکتی و اطمینان از انطباق قانونی انتخاب شود.

معماری ERP و ساختار چندشرکتی

هنگام طراحی ERP معماری برای شرکت‌های گروهی، هدف اصلی حفظ استقلال عملیاتی در عین گردآوری عملیات اشخاص حقوقی مختلف تحت یک چتر دیجیتال است. یکی از مفاهیم اساسی که در این مرحله با آن مواجه می‌شویم، ساختار tenant است. در سناریوهای چندشرکتی (multi-company یا multi-tenant)، سه رویکرد اصلی وجود دارد که می‌توان در مرحله طراحی پایگاه داده دنبال کرد: پایگاه‌های داده جداگانه، ایزولاسیون مبتنی بر اسکیما و امنیت سطح سطر (Row-Level Security - RLS).

1. رویکرد پایگاه داده جداگانه

در این روش، یک پایگاه داده کاملاً مستقل از نظر فیزیکی یا منطقی برای هر شرکت ایجاد می‌شود.

• مزایا: بالاترین سطح ایزولاسیون داده‌ها را فراهم می‌کند. یک خطا یا نقض امنیتی که در پایگاه داده یک شرکت رخ دهد، مستقیماً بر دیگران تأثیر نمی‌گذارد.
• معایب: انتقال داده‌های بین شرکتی و گزارش‌دهی تلفیقی مشترک پرهزینه بوده و نیازمند لایه‌های یکپارچه‌سازی اضافی است.

2. ایزولاسیون مبتنی بر اسکیما

روی همان سرور پایگاه داده، یک اسکیمای (schema) پایگاه داده جداگانه برای هر شرکت تعریف می‌شود. ساختار جداول یکسان است اما اسکیماها ایزوله هستند.

• مزایا: هزینه‌های نگهداری مشترک را کاهش داده و انعطاف‌پذیری در پرس‌وجو میان اسکیماها را ارائه می‌دهد.
• معایب: پیچیدگی مدیریت پویای اسکیما در مرحله طراحی پایگاه داده می‌تواند بار اضافی برای تیم‌های توسعه ایجاد کند.

3. امنیت سطح سطر (RLS)

داده‌های تمامی شرکت‌ها در جداول یکسانی نگهداری می‌شوند اما یک شناسه شرکت (tenant id) به هر سطر اضافه می‌شود. به لطف قوانین در سطح پایگاه داده، کاربران تنها می‌توانند سطرهایی را که به آن‌ها دسترسی دارند مشاهده کنند.

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

مدیریت داده‌های اصلی مشترک و فرآیندهای تصمیم‌گیری

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

سناریوی فرضی: ساختار هلدینگ سه شرکتی و پیاده‌سازی RLS

در این سناریو، نحوه پیکربندی مدل امنیت سطح سطر (RLS) را برای یک هلدینگ با سه شخصیت حقوقی مختلف که در زمینه‌های تولید، لجستیک و خرده‌فروشی فعالیت می‌کنند، بررسی می‌کنیم. مدیریت هلدینگ تصمیم گرفته است که از یک پایگاه داده واحد و جداول مشترک برای کاهش کلیه هزینه‌های عملیاتی و دریافت گزارش‌های سودآوری تلفیقی لحظه‌ای استفاده کند. تیم توسعه با افزودن ستون 'tenant_id' به جداول فاکتورها، سفارش‌ها و گردش انبار کار را آغاز کرده است. هنگامی که شرکت تولیدی (Tenant A) وارد سیستم می‌شود، سیاست‌های امنیتی در سطح پایگاه داده فعال شده و صرفاً سطرهایی که دارای مقدار شناسه Tenant A هستند، مستقل از لایه برنامه فیلتر می‌شوند. به این ترتیب، کارکنان شرکت خرده‌فروشی به هیچ وجه نمی‌توانند به داده‌های تولید دسترسی پیدا کنند.

با این حال، این معماری مبادلات تجاری و عملکردی جدی را به همراه دارد. اگر ایندکس‌گذاری درستی روی جدول گردش انبار با میلیون‌ها سطر انجام نشود، شرط 'WHERE tenant_id = X' که به طور خودکار به هر پرس‌وجو اضافه می‌شود، موتور پایگاه داده را تحت فشار قرار داده و هزینه‌های طرح اجرای (execution plan) را افزایش می‌دهد. از منظر مدیریت خطا، اگر زمینه (context) تیننت ارسال شده از لایه برنامه فراموش شود یا به اشتباه تنظیم گردد، سناریوهای فاجعه‌باری رخ خواهد داد؛ زیرا در صورت نادیده گرفته شدن قوانین RLS، داده‌های تمامی شرکت‌ها ممکن است با یکدیگر مخلوط شوند. برای رفع این خطرات، مدیریت استخر اتصالات پایگاه داده (connection pooling) باید به شدت نظارت شده و تست‌های نفوذ خودکار در هر دوره اسپرینت اجرا شوند.

چک‌لیست پیاده‌سازی ایزولاسیون پایگاه داده ERP

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

1. تحلیل الزامات قانونی و مالی: قوانین محلی نگهداری داده در کشورهای محل فعالیت شرکت‌ها باید از پیش گزارش شوند که آیا ضرورت پایگاه داده جداگانه را ایجاد می‌کنند یا خیر.
2. استانداردسازی شناسه Tenant: ستون‌های تیننت با نوع داده بهینه شده (مانند UUID یا Integer) سازگار با ساختارهای کلید اصلی باید در تمامی جداول تعریف شوند.
3. کدگذاری سیاست‌های پایگاه داده: امنیت سطح سطر (RLS) یا دسترسی‌های مبتنی بر اسکیما باید مستقیماً در سطح پایگاه داده (stored procedures و security policies) و بدون اتکا به کد برنامه ایمن‌سازی شوند.
4. مدیریت استخر اتصالات و زمینه: برای جلوگیری از نشت وضعیت نشست (session state) یا زمینه اتصال در معماری‌های چندشرکتی، نشست‌های پایگاه داده باید پس از هر درخواست بازنشانی شوند.
5. تست‌های بار و یکپارچه‌سازی جامع: عملکرد مکانیزم‌های ایزولاسیون در درخواست‌های داده با حجم بالا که به طور همزمان از تیننت‌های مختلف می‌آیند، باید تست شود.

این چک‌لیست نقشه راهی برای به حداقل رساندن خطرات معماری قابل مواجهه در پروژه‌های Kurumsal Yazılım & ERP و تکمیل بی‌نقص فرآیندهای حسابرسی ارائه می‌دهد.

منابع

• Kurumsal Yazılım & ERP — Cy Logic Software