امن‌سازی سوپرسِت: امنیت سطری و ورود یکپارچه برای محیط‌های چندسکونتی

با توزیع فزاینده تحلیل داده در بین بخش‌های مختلف و شرکای خارجی، نمایش یک داشبورد یکپارچه و تک‌قطبی برای همه دیگر امکان‌پذیر نیست. Apache Superset یک پلتفرم قدرتمند و متن‌باز برای کاوش داده است، اما مدل امنیتی پیش‌فرض آن اغلب برای محیط‌های پیچیده و چندسکونتی (Multi-tenant) بیش از حد مجاز است. برای مقیاس‌دهی مؤثر، سازمان‌ها باید مرزهای سخت‌گیرانه‌ای برای داده‌ها اعمال کنند و مدیریت هویت را یکپارچه سازند. این راهنما شما را در پیاده‌سازی فنی امنیت سطری (RLS) و یکپارچه‌سازی ورود یکپارچه (SSO) همراهی می‌کند تا اطمینان حاصل شود که هر مستأجر (Tenant) تنها به داده‌هایی دسترسی دارد که مجاز به مشاهده آن‌هاست.

درک الزامات امنیتی در محیط‌های چندسکونتی

در یک راه‌اندازی چندسکونتی، «مستأجر» (Tenant) می‌تواند به بخش‌های مختلف یک شرکت یا مشتریان خارجی کاملاً متفاوت اشاره داشته باشد. چالش اصلی امنیتی، جلوگیری از نشت داده بین این گروه‌هاست. اگرچه Superset از کنترل دسترسی مبتنی بر نقش (RBAC) برای مدیریت *چه کسی* می‌تواند به داشبوردهای خاص دسترسی داشته باشد استفاده می‌کند، اما به طور خودکار محدود نمی‌کند که *کدام ردیف‌ها* از داده‌ها توسط این کاربران در یک پایگاه داده مشترک قابل مشاهده باشد. اینجاست که RLS حیاتی می‌شود. در ترکیب با SSO، شما یک لایه هویت یکپارچه ایجاد می‌کنید که ویژگی‌های کاربر را به بافت‌های امنیتی منتقل می‌کند و امکان کنترل دسترسی پویا و مبتنی بر ویژگی را فراهم می‌آورد.

پیاده‌سازی امنیت سطری (RLS)

RLS در Superset از طریق فیلترهایی پیاده‌سازی می‌شود که بر اساس گروه یا ادعاهای (claims) کاربر به صورت خودکار به کوئری‌های SQL اضافه می‌شوند. این فیلترها با استفاده از قالب‌بندی Jinja تعریف می‌شوند و امکان پویا بودن بر اساس ویژگی‌های کاربری که در زمان احراز هویت ارائه می‌شوند را دارند.

برای مثال، اگر از یک ارائه‌دهنده LDAP یا SAML استفاده می‌کنید که شامل ویژگی `department` است، می‌توانید یک سیاست RLS ایجاد کنید که کاربران را به داده‌های بخش خودشان محدود کند. مثال زیر نشان می‌دهد که چگونه یک فیلتر RLS پویا برای جدول `sales` را پیکربندی کنید:

# در رابط کاربری Superset: تنظیمات > شنونده‌ها (Listeners) > سیاست‌های RLS
# نام سیاست: Tenant_Only_Sales_Data
# جدول: sales
# قالب فیلتر:
region == "{{ user.attrs['region'] }}"

این کار اطمینان حاصل می‌کند که وقتی کاربر با `region: 'APAC'` وارد سیستم می‌شود، کوئری SQL تولید شده به طور خودکار `WHERE region = 'APAC'` را اضافه می‌کند و دیدگاه او را ایزوله می‌کند. برای مدیریت این سیاست‌ها به صورت برنامه‌ای یا در محیط‌های بزرگ، می‌توانید از REST API Superset استفاده کنید:

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():
        # این هوک (hook) می‌تواند برای اعتبارسنجی ادعاهای خاص گسترش یابد
        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` تزریق می‌شوند. علاوه بر این، با موارد حاشیه‌ای (Edge cases) تست کنید: کاربرانی که ویژگی خاص را ندارند، کاربرانی که به چندین گروه تعلق دارند و جلسات SSO منقضی شده.

نتیجه‌گیری

امن‌سازی Apache Superset برای تحلیل‌های چندسکونتی نیازمند یک رویکرد دوگانه است: اعمال ایزوله‌سازی داده از طریق امنیت سطری (RLS) و تمرکز اعتماد از طریق SSO. با بهره‌گیری از فیلترهای RLS پویا که توسط ویژگی‌های SSO هدایت می‌شوند، شما یک محیط مقیاس‌پذیر، قابل ممیزی و امن ایجاد می‌کنید. این معماری نه تنها داده‌های حساس را محافظت می‌کند، بلکه مدیریت کاربران را نیز ساده می‌کند و به مدیران اجازه می‌دهد دسترسی را از طریق ارائه‌دهنده هویت موجود خود مدیریت کنند، به جای نگهداری رکوردهای کاربری جداگانه در Superset. با رشد سازمان شما، این مدل امنیتی بنیادین اطمینان حاصل می‌کند که پلتفرم تحلیلی شما هم قدرتمند و هم مطابق با استانداردها باقی بماند.