Masquer les PII des traces OpenTelemetry dans Unity Catalog
Les données de trace OpenTelemetry (OTel) contiennent souvent des informations personnelles identifiables (PII) telles que des adresses e-mail, des numéros de téléphone et des numéros de carte de crédit intégrées dans les attributs d'étendue, les corps de log et les métadonnées de ressources. Le partage généralisé de ces données de trace à des fins de debugging ou d'observabilité peut créer des risques de conformité et de confidentialité.
Cette page décrit une solution type qui utilise les AI Functions et les Spark Declarative Pipelines pour rédiger de manière incrémentielle les informations PII des tables OTel brutes et écrire les résultats dans un ensemble distinct de tables avec des contrôles d’accès plus larges. Un Job de rétention configurable gère le nettoyage des données brutes. Déployez les assets téléchargeables dans votre propre workspace et adaptez-les à vos exigences.
Vous pouvez utiliser cette solution avec toutes les traces OTel stockées dans Unity Catalog, y compris Stocker les traces OpenTelemetry dans Unity Catalog.
Pour éviter que les PII ne soient stockées en premier lieu, masquez les PII des traces avant l'exportation.
Comment cela fonctionne
Un Lakeflow pipeline lit de manière incrémentielle de nouvelles étendues OTel, applique ai_mask pour masquer les PII (e-mails, téléphones, SSN, cartes de crédit, noms et adresses), et écrit dans les tables masquées. Un Job planifié gère le nettoyage optionnel de la rétention sur les tables brutes.
Prérequis
- Un Workspace compatible avec Unity Catalog.
- AI Functions disponibles via un SQL Warehouse Serverless ou un pipeline Serverless.
- Le Databricks CLI s’est authentifié sur votre Workspace.
- Données de trace OTel dans les tables Unity Catalog, écrites via MLflow, un exportateur OTel ou tout client OTLP. Consultez Stocker les traces OpenTelemetry dans Unity Catalog.
download les ressources
download les fichiers suivants et importez-les dans votre Workspace :
Fichier | Description |
|---|---|
Notebook de déploiement guidé — alternative interactive à | |
Script de déploiement CLI. | |
Le pipeline – tables de streaming avec | |
Vue de trace unifiée joignant les portées et les annotations. | |
Création de schémas et octroi de contrôles d’accès. | |
Exemple de configuration de pipeline (référence). | |
Utilitaire de test qui envoie des données de test PII sous forme de spans OTel. | |
50 lignes de données de test PII synthétiques. |
Pour plus de détails, consultez la documentation de référence.
Déployer la solution
Sélectionnez l'une des méthodes de déploiement suivantes.
- Guided notebook (recommended)
- CLI
- Manual
Pour un déploiement étape par étape directement dans votre Workspace :
- Importez deploy_notebook.py dans votre Workspace, ainsi que les autres assets téléchargés. Consultez les dossiers Git Databricks.
- Ouvrez
deploy_notebook.pydans votre workspace. - Remplissez les paramètres du widget en haut (catalogue, schéma source, schéma cible et préfixe de table).
- Cliquez sur **Tout exécuter**. Chaque étape est validée avant de continuer.
Cette approche utilise le SDK Python Databricks (aucun CLI requis), peut être réexécutée en toute sécurité et fournit un feedback interactif à chaque étape.
Exécutez le script de déploiement avec les détails de votre Workspace :
./deploy.sh <WORKSPACE_HOST> <CATALOG> <SOURCE_SCHEMA> <TARGET_SCHEMA> <TABLE_PREFIX>
Par exemple :
./deploy.sh https://my-workspace.cloud.databricks.com my_catalog traces_raw traces_redacted my_app
Le script effectue les opérations suivantes :
- Uploade le SQL du pipeline vers votre workspace.
- Crée le schéma cible.
- Crée et déclenche le pipeline.
- Configure l’auto-TTL sur les tables brutes (si
retention_daysest défini).
Une fois le pipeline terminé, exécutez unified_view.sql pour créer la vue de trace unifiée. Remplacez les variables ${...} par vos valeurs.
Pour configurer les choses étape par étape :
- Créez le schéma cible. Exécutez les instructions dans
setup_schema_and_grants.sql. - Upload du pipeline SQL. Importez
pii_redaction_pipeline.sqldans votre Workspace. - **Créez le pipeline.** Utilisez
pipeline_config.jsoncomme template et remplacez les valeurs<PLACEHOLDER>. - Trigger a pipeline run. Utilisez l'interface utilisateur ou exécutez
databricks pipelines start-update <PIPELINE_ID>. - Créez la vue unifiée. Exécutez
unified_view.sqlaprès la première exécution du pipeline. - Configurer la rétention. Activer la durée de vie automatique sur les tables brutes. Voir la référence de la rédaction des informations personnelles identifiables (PII) des traces OTel.
parameter
Le tableau suivant décrit les paramètres du widget dans le Notebook de déploiement guidé (deploy_notebook.py) :
parameter | Description | Par défaut |
|---|---|---|
| Catalogue Unity Catalog pour les tables brutes et censurées. | (obligatoire) |
| Schéma contenant les tables brutes OTel. | (obligatoire) |
| Schéma des tables de sortie expurgées. | (obligatoire) |
| Préfixe utilisé pour les noms de table OTel. | (obligatoire) |
| Types de PII à masquer, séparés par des virgules et entre guillemets simples. |
|
| Nom du pipeline. |
|
| Jours de conservation des données brutes avant suppression. Une valeur vide, |
|
| Mode d'exécution du pipeline : |
|
| Fréquence d'exécution du pipeline (mode Trigger uniquement) : |
|
Les tables sources sont nommées {catalog}.{source_schema}.{table_prefix}_otel_spans, {catalog}.{source_schema}.{table_prefix}_otel_logs et {catalog}.{source_schema}.{table_prefix}_otel_annotations.
Le pipeline prend en charge deux modes d'exécution :
- Déclencher : Crée un Job planifié qui déclenche le pipeline à la fréquence choisie. Le pipeline traite les nouvelles données à chaque exécution, puis s'arrête.
- continu : Exécute le pipeline en continu, traitant les nouvelles données au fur et à mesure qu'elles arrivent. Aucun job de planification n'est créé. Ce mode a des coûts de compute plus élevés que le mode Trigger, car le pipeline est toujours en cours d'exécution.
Ce qui est expurgé
Le pipeline applique ai_mask aux champs suivants :
Table | Champs masqués |
|---|---|
Portées |
|
Journaux |
|
Annotations | Passthrough (aucune PII attendue) |
Le pipeline préserve les champs non-PII inchangés, tels que les ID de trace, les ID de span, les timestamps, les noms de service et les codes d'état.
Catégories de PII prises en charge
ai_mask est pris en charge par le LLM et reconnaît les types de PII standard, notamment : email, phone, name, address, ssn, credit_card, ip_address et date_of_birth.
ai_mask est recommandé car il gère différents formats de PII (par exemple, des numéros de téléphone écrits comme (555) 123-4567, 555.123.4567 ou +1 555-123-4567) sans nécessiter un modèle distinct pour chaque variation. Vous pouvez adapter le pipeline pour utiliser une autre méthode de masquage, par exemple des expressions régulières explicites avec regexp_replace.
Pour les modèles personnalisés, tels que les identifiants d'employés comme EMP-XXXXXX, utilisez regexp_replace avant ai_mask dans le SQL du pipeline. Pour plus de détails, consultez la référence de rédaction PII à partir des traces OTel.
Rétention et contrôle d’accès
Conservation des données brutes
Le déploiement configure une durée de vie automatique sur les tables OTel brutes afin de supprimer automatiquement les données de trace de plus de 90 jours (default : 90). Cela vous aide à vous conformer au GDPR et aux autres réglementations pour la protection des données qui exigent que les données personnelles soient supprimées après qu'elles ne soient plus nécessaires à leur objectif initial. Une fois que le pipeline a traité les étendues brutes, la durée de vie automatique (auto-TTL) supprime les originaux qui contiennent des informations personnelles identifiables (PII) conformément à votre politique de rétention. Définissez retention_days sur 0 ou none pour désactiver la suppression automatique si vous gérez la rétention séparément. Si vos exigences de conformité nécessitent des délais de suppression stricts, vous pouvez configurer un Job planifié manuellement avec DELETE et VACUUM à la place, car le calendrier exact de suppression de la durée de vie automatique (auto-TTL) n'est pas garanti.
Limiter l'accès aux tables brutes
Les tables OTel brutes contiennent des informations personnelles identifiables (PII) non expurgées et devraient avoir un accès restreint. Accordez l'accès au schéma source brut uniquement aux Service Principal de pipeline et aux administrateurs qui en ont besoin pour le debugging ou la réponse aux incidents. Toutes les analyses de routine, les tableaux de bord et les workflows d'observabilité devraient plutôt query les tables expurgées. Le fichier setup_schema_and_grants.sql comprend des exemples d'autorisations pour aider à appliquer cette séparation. Pour plus d'informations sur les privilèges Unity Catalog, consultez Gérer les privilèges dans Unity Catalog.
Testez la rédaction
Envoyer des données PII de test
Générer des étendues de test avec des PII connues pour valider la rédaction :
pip install opentelemetry-exporter-otlp-proto-http
python send_pii_traces.py <WORKSPACE_HOST> <CATALOG.SCHEMA.PREFIX_otel_spans>
Cela envoie 50 traces de test qui contiennent des e-mails, des numéros de téléphone, des numéros de sécurité sociale, des cartes de crédit, des noms et des adresses.
Valider la sortie
Après l'exécution du pipeline, comparez les étendues brutes et expurgées :
SELECT
s.span_id,
CAST(s.attributes AS STRING) AS raw,
CAST(r.attributes AS STRING) AS redacted
FROM <source_catalog>.<source_schema>.<prefix>_otel_spans s
JOIN <target_catalog>.<target_schema>.redacted_spans r
ON s.trace_id = r.trace_id AND s.span_id = r.span_id
WHERE s.name = 'pii-test-interaction'
LIMIT 5;