Veri analitiği departmanlar ve dış ortaklar arasında giderek daha dağınık hale geldikçe, herkese tek bir monolitik gösterge paneli sunmak artık uygulanabilir değil. Apache Superset güçlü, açık kaynaklı bir veri keşif platformudur, ancak varsayılan güvenlik modeli genellikle karmaşık, çok kiracılı ortamlar için çok fazla izin verir. Etkili bir şekilde ölçeklenmek için kuruluşlar, sıkı veri sınırları uygulamalı ve kimlik yönetimini birleştirmelidir. Bu kılavuz, Satır Düzeyli Güvenlik (RLS) ve Tek Oturum Açma (SSO) entegrasyonunun teknik uygulamasını adım adım anlatarak her kiracının yalnızca erişim yetkisi olan verilere bakmasını sağlar.
Çok Kiracılı Güvenlik Gereksinimlerini Anlama
Çok kiracılı bir kurulumda "kiracı", bir şirket içindeki farklı departmanlara veya tamamen farklı dış müşterilere atıfta bulunabilir. Temel güvenlik zorluğu, bu gruplar arasında veri sızıntısını önlemektir. Superset, belirli gösterge panellerine *kimin* erişebileceğini yönetmek için Rol Tabanlı Erişim Kontrolü (RBAC) sağlasa da, paylaşılan bir veritabanında bu kullanıcıların *hangi satırları* görebileceğini otomatik olarak kısıtlamaz. İşte RLS burada kritik hale gelir. SSO ile birleştirildiğinde, kullanıcı özniteliklerini güvenlik bağlamlarına aktaran birleşik bir kimlik katmanı oluşturursunuz; bu da dinamik, öznitelik tabanlı erişim kontrolüne olanak tanır.
Satır Düzeyli Güvenlik (RLS) Uygulaması
Superset'teki RLS, kullanıcının grubuna veya iddialarına (claims) göre SQL sorgularına otomatik olarak eklenen filtreler aracılığıyla uygulanır. Bu filtreler, Jinja şablonlama kullanılarak tanımlanır ve bu da kimlik doğrulama sırasında sağlanan kullanıcı özniteliklerine göre dinamik olmalarına olanak tanır.
Örneğin, `department` (departman) özniteliğini içeren bir LDAP veya SAML sağlayıcısı kullanıyorsanız, kullanıcıları kendi departmanlarının verileriyle sınırlayan bir RLS politikası oluşturabilirsiniz. Aşağıdaki örnek, bir `sales` (satış) tablosu için dinamik bir RLS filtresinin nasıl yapılandırılacağını göstermektedir:
# Superset Arayüzünde: Ayarlar > Dinleyiciler > RLS Politikaları
# Politika Adı: Tenant_Only_Sales_Data
# Tablo: sales
# Filtre Şablonu:
region == "{{ user.attrs['region'] }}"
Bu, bir kullanıcı `region: 'APAC'` ile giriş yaptığında, oluşturulan SQL sorgusunun otomatik olarak `WHERE region = 'APAC'` eklemesini ve görünümlerini izole etmesini sağlar. Bu politikaları programatik olarak veya büyük ortamlarda yönetmek için Superset REST API'sini kullanabilirsiniz:
import requests
import json
# Yapılandırma
BASE_URL = "http://your-superset-instance/api/v1"
HEADERS = {"Authorization": "Bearer ", "Content-Type": "application/json"}
# RLS Politikasını Tanımla
rls_policy = {
"filter": "region == \"{{ user.attrs['region'] }}\"",
"table_id": 42, # 'sales' tablosunun ID'si
"name": "Tenant Region Lock",
"roles": [1, 5] # Bu politikanın uygulandığı rollerin ID'leri
}
# Politikayı Oluştur
response = requests.post(f"{BASE_URL}/row_level_security", data=json.dumps(rls_policy), headers=HEADERS)
print(response.json())
Birleşik Kimlik İçin SSO Entegrasyonu
SSO entegrasyonu sadece kolaylık meselesi değildir; güvenli çok kiracılılığın omurgasıdır. Superset'i SAML2 veya OpenID Connect yoluyla Okta, Azure AD veya Auth0 gibi bir Kimlik Sağlayıcıya (IdP) entegre ederek kimlik doğrulamayı merkezileştirirsiniz. Daha da önemlisi, IdP özniteliklerini (gruplar, e-posta alanları, özel iddialar) Superset rollerine ve RLS bağlamlarına eşleyebilirsiniz.
Örneğin, `superset` yapılandırma dosyasını (`superset_config.py`) kullanarak, yalnızca IdP belirteçlerinde `superset-admin` iddiası olan kullanıcıların yönetim arayüzüne erişmesine izin verebilirsiniz:
import os
from superset.extensions import db
from flask import g
class SupersetConfig:
# SAML Yapılandırma Örneği
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 veya belirli iddiaları uygulamak için özel giriş gerekli
@staticmethod
def login_required():
# Bu kanca, belirli iddiaları doğrulamak için genişletilebilir
if not g.user:
return False
# Örnek: Üretimde belirli alanlardan gelen kullanıcıları engelle
if g.user.email and g.user.email.endswith('@test.com'):
raise Exception("Test hesapları üretimde engellenmiştir")
return True
# IdP Gruplarını Superset Rollerine Eşle
@staticmethod
def map_login_user(user, attrs):
# 'attrs', SSO belirtecinden gelen iddiaları içerir
if 'data-analyst' in attrs.get('groups', []):
# IdP gruplarına göre rolleri dinamik olarak atayın
pass
return user
Test ve Doğrulama
Bu yapılandırmayı üretime dağıtmadan önce, RLS mantığını doğrulamak kritiktir. Superset'in "SQL Lab" aracı bunun için mükemmel bir araçtır, çünkü oluşturulan sorgu dizesini gösterir. Bir test kullanıcısı olarak sorgu çalıştırırken, RLS filtrelerinin `WHERE` koşuluna doğru şekilde enjekte edildiğini doğrulayın. Ayrıca kenar durumlarıyla test edin: belirli özniteliğe sahip olmayan kullanıcılar, birden fazla gruba ait kullanıcılar ve süresi dolmuş SSO oturumları.
Sonuç
Apache Superset'i çok kiracılı analitik için güvence altına almak iki yönlü bir yaklaşım gerektirir: Satır Düzeyli Güvenlik ile veri izolasyonunu uygulamak ve SSO ile güveni merkezileştirmek. SSO öznitelikleriyle yönlendirilen dinamik RLS filtrelerinden yararlanarak, ölçeklenebilir, denetlenebilir ve güvenli bir ortam oluşturursunuz. Bu mimari yalnızca hassas verileri korumakla kalmaz, aynı zamanda yöneticilerin ayrı Superset kullanıcı kayıtları sürdürmek yerine mevcut Kimlik Sağlayıcıları üzerinden erişimi yönetmesine olanak tanıyarak kullanıcı yönetimini de basitleştirir. Kuruluşunuz büyüdükçe, bu temel güvenlik modeli, analitik platformunuzun hem güçlü hem de uyumlu kalmasını sağlar.
<<<