Masquage des données

Le masquage des données anonymise les colonnes sensibles dès qu'une branche est créée. Vous attachez une politique de masquage à l'appel de création de branche, et les colonnes correspondantes de la nouvelle branche sont réécrites de façon irréversible — hachées, mises à NULL, tronquées ou remplacées — avant que la branche ne soit jamais accessible. La branche parente n'est jamais modifiée.

Vous y recourez pour fournir des données ayant la forme de la production au développement, à la CI ou à un prestataire sans leur livrer les données personnelles qu'elles contiennent : formes de tables réelles, nombres de lignes réels, e-mails factices.

Comment ça fonctionne

Une politique de masquage est un ensemble nommé de règles, à la portée du projet. Chaque règle fait correspondre des colonnes par motif et nomme une fonction de masquage intégrée :

À la création de la branche, lorsqu'un masking_policy_id est fourni :

1. La branche se détache de son parent comme d'habitude (copy-on-write — instantané).
2. La branche entre dans l'état masking. Aucun endpoint n'est provisionné et le proxy refuse les connexions vers elle : il n'existe aucune fenêtre pendant laquelle les données pré-masquées peuvent être lues.
3. Un worker de masquage se connecte au compute de la branche avec un rôle à moindre privilège, découvre le schéma, fait correspondre vos règles à celui-ci, et exécute chaque réécriture dans une seule transaction.
4. La branche atterrit dans l'état ready et ses endpoints démarrent — ne servant désormais que des données masquées. En cas d'échec quelconque, la branche atterrit dans l'état failed et reste scellée ; supprimez-la et réessayez.

Les entrées des règles sont traitées comme des données, jamais comme du SQL : les identifiants sont mis entre guillemets et les valeurs des arguments sont liées comme paramètres à l'exécution, de sorte qu'un nom de colonne ou une constante hostile ne peut pas s'échapper de la réécriture.

Fonctions intégrées

Le catalogue est également servi par l'API :

curl -s https://api.test.kisenon.com/v1/masking-functions \
  -H "Authorization: Bearer $KISENON_API_KEY"

Gérer les politiques

Le masquage des données est en cours de déploiement. L'éditeur de politiques et la liste déroulante de création de branche décrits ici sont activés progressivement ; tant que le masquage n'est pas actif pour votre compte, l'API répond 501 not_implemented et la console affiche un avis « pas encore disponible ». Vos projets ne sont pas affectés entre-temps.

Dans la console, ouvrez Project settings → Data masking pour créer une politique : nommez-la, ajoutez des règles (colonnes par motif + une liste déroulante de fonctions), et enregistrez. La même surface existe sur l'API :

curl -s -X POST \
  https://api.test.kisenon.com/v1/projects/$PROJECT_ID/masking-policies \
  -H "Authorization: Bearer $KISENON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dev-safe",
    "rules": [
      {"table_pattern": "users", "column_pattern": "email", "masking_fn": "mask_email"},
      {"table_pattern": "users", "column_pattern": "phone", "masking_fn": "mask_null"},
      {"table_pattern": "%", "column_pattern": "%ssn%", "masking_fn": "mask_ssn_partial"}
    ]
  }'

Créez ensuite une branche masquée en ajoutant la politique à un appel de création de branche normal :

curl -s -X POST \
  https://api.test.kisenon.com/v1/projects/$PROJECT_ID/branches \
  -H "Authorization: Bearer $KISENON_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "masked-dev", "masking_policy_id": "'$POLICY_ID'"}'

La branche signale state: "masking" pendant l'exécution de la réécriture ; observez-la basculer vers ready dans la console (en direct, via le flux d'événements du projet) ou en interrogeant GET /v1/branches/{id}.

Bon à savoir

• Le masquage est ponctuel, à la création. Modifier une politique ne touche jamais les branches déjà créées avec elle — elles conservent la forme de données avec laquelle elles sont nées. Recréez la branche pour appliquer les nouvelles règles.
• Une politique en cours d'utilisation ne peut pas être supprimée. Supprimer une politique avec laquelle une branche active a été créée renvoie 409 policy_in_use ; supprimez d'abord ces branches.
• Les règles non appariées sont ignorées, pas fatales. Si votre schéma a dérivé et qu'un motif ne correspond à rien, la branche se termine quand même — vérifiez les motifs des règles si une colonne que vous attendiez masquée a toujours la forme de données réelle.
• Les incompatibilités de type font échouer la branche. Une règle qui correspond à une colonne que sa fonction ne peut pas réécrire (disons mask_email sur un integer) interrompt tout le masque — la branche atterrit dans l'état failed et n'est jamais exposée à moitié masquée.