Technical Tutorials

À mesure que l'analyse de données se distribue de plus en plus entre les départements et les partenaires externes, exposer un tableau de bord monolithique unique à tous n'est plus viable. Apache Superset est une puissante plateforme open source d'exploration de données, mais son modèle de sécurité par défaut est souvent trop permissif pour les environnements multi-locataires complexes. Pour passer à l'échelle efficacement, les organisations doivent imposer des limites de données strictes et unifier la gestion des identités. Ce guide vous accompagne dans l'implémentation technique de la sécurité au niveau des lignes (RLS) et de l'intégration du Single Sign-On (SSO), garantissant que chaque locataire ne voit que ce à quoi il est autorisé d'accéder.

Comprendre les exigences de sécurité multi-locataire

Dans une configuration multi-locataire, le terme « locataire » peut désigner différents départements au sein d'une entreprise ou des clients externes entièrement distincts. Le défi de sécurité principal est de prévenir la fuite de données entre ces groupes. Bien que Superset fournisse un contrôle d'accès basé sur les rôles (RBAC) pour gérer *qui* peut accéder à des tableaux de bord spécifiques, il ne restreint pas automatiquement *lesquelles lignes* de données ces utilisateurs peuvent voir au sein d'une base de données partagée. C'est là que la RLS devient cruciale. Combinée au SSO, elle crée une couche d'identité unifiée qui propage les attributs des utilisateurs dans les contextes de sécurité, permettant un contrôle d'accès dynamique basé sur les attributs.

Mise en œuvre de la sécurité au niveau des lignes (RLS)

La RLS dans Superset est implémentée via des filtres qui sont automatiquement ajoutés aux requêtes SQL en fonction du groupe ou des revendications (claims) de l'utilisateur. Ces filtres sont définis à l'aide de la templating Jinja, leur permettant d'être dynamiques en fonction des attributs d'utilisateur fournis lors de l'authentification.

Par exemple, si vous utilisez un fournisseur LDAP ou SAML qui inclut un attribut `department`, vous pouvez créer une politique RLS qui restreint les utilisateurs aux données de leur propre département. L'exemple suivant montre comment configurer un filtre RLS dynamique pour une table `sales` :

# Dans l'interface Superset : Paramètres > Listeners > Politiques RLS
# Nom de la politique : Tenant_Only_Sales_Data
# Table : sales
# Modèle de filtre :
region == "{{ user.attrs['region'] }}"

Cela garantit que lorsqu'un utilisateur se connecte avec `region: 'APAC'`, la requête SQL générée ajoute automatiquement `WHERE region = 'APAC'`, isolant ainsi sa vue. Pour gérer ces politiques de manière programmatique ou dans de grands environnements, vous pouvez utiliser l'API REST de Superset :

import requests
import json

# Configuration
BASE_URL = "http://votre-instance-superset/api/v1"
HEADERS = {"Authorization": "Bearer ", "Content-Type": "application/json"}

# Définir la politique RLS
rls_policy = {
    "filter": "region == \"{{ user.attrs['region'] }}\"",
    "table_id": 42,  # ID de la table 'sales'
    "name": "Verrouillage de région du locataire",
    "roles": [1, 5]  # IDs des rôles auxquels cette politique s'applique
}

# Créer la politique
response = requests.post(f"{BASE_URL}/row_level_security", data=json.dumps(rls_policy), headers=HEADERS)
print(response.json())

Intégration du SSO pour une identité unifiée

L'intégration du SSO ne se limite pas à la commodité ; c'est la pierre angulaire d'une multi-locataire sécurisée. En intégrant Superset à un fournisseur d'identité (IdP) comme Okta, Azure AD ou Auth0 via SAML2 ou OpenID Connect, vous centralisez l'authentification. Plus important encore, vous pouvez mapper les attributs de l'IdP (groupes, domaines d'e-mail, revendications personnalisées) aux rôles Superset et aux contextes RLS.

Par exemple, en utilisant le fichier de configuration `superset` (`superset_config.py`), vous pouvez imposer que seuls les utilisateurs possédant la revendication `superset-admin` dans leur jeton IdP puissent accéder à l'interface d'administration :

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

class SupersetConfig:
    # Exemple de configuration 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,
    }

    # Connexion personnalisée requise pour imposer la MFA ou des revendications spécifiques
    @staticmethod
    def login_required():
        # Ce hook peut être étendu pour valider des revendications spécifiques
        if not g.user:
            return False
        # Exemple : Bloquer les utilisateurs de domaines spécifiques en production
        if g.user.email and g.user.email.endswith('@test.com'):
            raise Exception("Les comptes de test sont bloqués en production")
        return True

    # Mapper les groupes IdP aux rôles Superset
    @staticmethod
    def map_login_user(user, attrs):
        # 'attrs' contient les revendications du jeton SSO
        if 'data-analyst' in attrs.get('groups', []):
            # Attribuer dynamiquement des rôles en fonction des groupes IdP
            pass
        return user

Tests et validation

Avant de déployer cette configuration en production, il est crucial de valider la logique RLS. Le « SQL Lab » de Superset est un excellent outil à cet effet, car il affiche la chaîne de requête générée. Lors de l'exécution d'une requête en tant qu'utilisateur de test, vérifiez que les filtres RLS sont injectés correctement dans la clause `WHERE`. De plus, testez avec des cas limites : utilisateurs sans l'attribut spécifique, utilisateurs appartenant à plusieurs groupes et sessions SSO expirées.

Conclusion

Sécuriser Apache Superset pour l'analytique multi-locataire nécessite une approche à double détente : imposer l'isolation des données via la sécurité au niveau des lignes et centraliser la confiance via le SSO. En exploitant des filtres RLS dynamiques pilotés par les attributs SSO, vous créez un environnement évolutif, auditable et sécurisé. Cette architecture non seulement protège les données sensibles, mais simplifie également la gestion des utilisateurs, permettant aux administrateurs de gérer l'accès via leur fournisseur d'identité existant plutôt que de maintenir des enregistrements d'utilisateurs Superset séparés. À mesure que votre organisation grandit, ce modèle de sécurité fondamental garantit que votre plateforme analytique reste à la fois puissante et conforme.