تأمين Superset: الأمان على مستوى الصفوف وتسجيل الدخول الموحد للبيئات متعددة المستأجرين

مع تزايد توزيع تحليلات البيانات عبر الأقسام والشركاء الخارجيين، لم يعد من الممكن عرض لوحة تحكم واحدة شاملة للجميع. Apache Superset هو منصة استكشاف بيانات قوية ومفتوحة المصدر، لكن نموذج الأمان الافتراضي فيه غالبًا يكون مفرطًا في السماحية للبيئات المعقدة متعددة المستأجرين. لكي يتم التوسع بفعالية، يجب على المنظمات فرض حدود صارمة للبيانات وتوحيد إدارة الهوية. يشرح هذا الدليل التنفيذ التقني للأمان على مستوى الصفوف (RLS) وتكامل تسجيل الدخول الموحد (SSO)، مما يضمن أن يرى كل مستأجر فقط ما هو مصرح له بالوصول إليه.

فهم متطلبات الأمان في البيئات متعددة المستأجرين

في الإعداد متعدد المستأجرين، يمكن أن يشير مصطلح "المستأجر" إلى أقسام مختلفة داخل شركة أو إلى عملاء خارجيين مختلفين تمامًا. التحدي الأمني الأساسي هو منع تسرب البيانات بين هذه المجموعات. بينما يوفر Superset التحكم في الوصول بناءً على الأدوار (RBAC) لإدارة *من* يمكنه الوصول إلى لوحات تحكم محددة، إلا أنه لا يقيّد تلقائيًا *أي صفوف* من البيانات يمكن لمستخدميها رؤيتها داخل قاعدة بيانات مشتركة. هنا يصبح RLS حاسمًا. عند دمجه مع SSO، تنشئ طبقة هوية موحدة تنقل سمات المستخدم إلى سياقات الأمان، مما يتيح التحكم الديناميكي في الوصول بناءً على السمات.

تنفيذ الأمان على مستوى الصفوف (RLS)

يتم تنفيذ RLS في Superset عبر فلاتر تُضاف تلقائيًا إلى استعلامات SQL بناءً على مجموعة المستخدم أو المطالبات (claims). تُعرّف هذه الفلاتر باستخدام قوالب Jinja، مما يسمح بأن تكون ديناميكية بناءً على سمات المستخدم المقدمة أثناء المصادقة.

على سبيل المثال، إذا كنت تستخدم مزود LDAP أو SAML يتضمن سمة `department` (قسم)، يمكنك إنشاء سياسة RLS تقيد المستخدمين ببيانات قسمهم فقط. يوضح المثال التالي كيفية تكوين فلتر RLS ديناميكي لجداول `sales` (المبيعات):

# في واجهة Superset: الإعدادات > المستمعون > سياسات RLS
# اسم السياسة: Tenant_Only_Sales_Data
# الجدول: sales
# قالب الفلتر:
region == "{{ user.attrs['region'] }}"

يضمن هذا أنه عندما يسجل المستخدم الدخول مع `region: 'APAC'`، يضيف الاستعلام SQL المولد تلقائيًا `WHERE region = 'APAC'`، مما يعزل رؤيته. لإدارة هذه السياسات برمجيًا أو في البيئات الكبيرة، يمكنك استخدام واجهة برمجة تطبيقات Superset REST:

import requests
import json

# التهيئة
BASE_URL = "http://your-superset-instance/api/v1"
HEADERS = {"Authorization": "Bearer ", "Content-Type": "application/json"}

# تعريف سياسة RLS
rls_policy = {
    "filter": "region == \"{{ user.attrs['region'] }}\"",
    "table_id": 42,  # معرف جدول 'sales'
    "name": "Tenant Region Lock",
    "roles": [1, 5]  # معرفات الأدوار التي تنطبق عليها هذه السياسة
}

# إنشاء السياسة
response = requests.post(f"{BASE_URL}/row_level_security", data=json.dumps(rls_policy), headers=HEADERS)
print(response.json())

تكامل SSO للهوية الموحدة

تكامل SSO ليس مجرد مسألة ملاءمة؛ بل هو العمود الفقري للأمان الآمن متعدد المستأجرين. من خلال دمج Superset مع مزود هوية (IdP) مثل Okta أو Azure AD أو Auth0 عبر SAML2 أو OpenID Connect، تقوم بتوحيد المصادقة. والأهم من ذلك، يمكنك ربط سمات IdP (المجموعات، نطاقات البريد الإلكتروني، المطالبات المخصصة) بأدوار Superset وسياقات RLS.

على سبيل المثال، باستخدام ملف التهيئة `superset` (`superset_config.py`)، يمكنك فرض أن المستخدمين الذين لديهم سمة `superset-admin` في رمز IdP الخاص بهم فقط هم من يمكنهم الوصول إلى واجهة الإدارة:

import os
from superset.extensions import db
from flask import g

class SupersetConfig:
    # مثال على تهيئة SAML
    SAMLP = {
        "SAML_PATH": os.environ.get("SAML_PATH", "/saml"),
        "IDP_METADATA_PATH": os.environ.get("IDP_METADATA_PATH", "/path/to/idp.xml"),
        "SP_NAME": "Superset-Analytics",
        "SP_ENTITY_ID": "https://analytics.company.com",
        "SAML_ENABLED": True,
    }

    # تسجيل دخول مخصص مطلوب لفرض MFA أو مطالبات محددة
    @staticmethod
    def login_required():
        # يمكن توسيع هذا الخطاف للتحقق من مطالبات محددة
        if not g.user:
            return False
        # مثال: حظر المستخدمين من نطاقات محددة في بيئة الإنتاج
        if g.user.email and g.user.email.endswith('@test.com'):
            raise Exception("حسابات الاختبار محظورة في بيئة الإنتاج")
        return True

    # ربط مجموعات IdP بأدوار Superset
    @staticmethod
    def map_login_user(user, attrs):
        # تحتوي 'attrs' على المطالبات من رمز SSO
        if 'data-analyst' in attrs.get('groups', []):
            # تعيين الأدوار ديناميكيًا بناءً على مجموعات IdP
            pass
        return user

الاختبار والتحقق

قبل نشر هذا التكوين في بيئة الإنتاج، من الحاسم التحقق من منطق RLS. أداة "SQL Lab" في Superset هي أداة ممتازة لهذا الغرض، حيث تعرض سلسلة الاستعلام المولدة. عند تنفيذ استعلام كمستخدم اختبار، تحقق من أن فلاتر RLS تُحقن بشكل صحيح في جملة `WHERE`. بالإضافة إلى ذلك، اختبر الحالات الحدية: مستخدمون بدون السمة المحددة، مستخدمون ينتمون إلى مجموعات متعددة، وجلسات SSO منتهية الصلاحية.

الخلاصة

تأمين Apache Superset لتحليلات متعددة المستأجرين يتطلب نهجًا مزدوجًا: فرض عزل البيانات من خلال الأمان على مستوى الصفوف وتوحيد الثقة من خلال SSO. من خلال الاستفادة من فلاتر RLS الديناميكية المدعومة بسمات SSO، تنشئ بيئة قابلة للتوسع وقابلة للتدقيق وآمنة. لا تحمي هذه البنية البيانات الحساسة فحسب، بل تبسط أيضًا إدارة المستخدمين، مما يسمح للمشرفين بإدارة الوصول من خلال مزود الهوية الخاص بهم بدلاً من الحفاظ على سجلات مستخدمين منفصلة في Superset. مع نمو مؤسستك، يضمن نموذج الأمان الأساسي هذا أن تبقى منصة التحليلات الخاصة بك قوية ومتوافقة مع المعايير.