Tous les produits
Search
Centre de documentation

PolarDB:Dynamic data masking

Dernière mise à jour :Aug 12, 2026

Cette rubrique présente la fonctionnalité de masquage dynamique des données fournie par PolarProxy.

Prérequis

La version de PolarProxy doit être V2.4.12 ou ultérieure. Pour savoir comment consulter la version actuelle et mettre à niveau PolarProxy, reportez-vous à Mise à jour de la version mineure.

Solutions de masquage des données

Si vous autorisez des tiers à générer des rapports, analyser des données, mener des activités de développement et de test ou exécuter d'autres opérations liées aux bases de données, vous pouvez avoir besoin d'obtenir en temps réel les dernières données client depuis les bases de données de production. Pour éviter toute divulgation d'informations personnelles, masquez les données avant de les transmettre à ces tiers. Alibaba Cloud propose deux solutions : le masquage dynamique et le masquage statique des données. PolarProxy utilise le masquage dynamique des données.

Tableau 1. Comparaison des solutions de masquage des données

Solution de masquage des données

Description

Avantages

Limites

Masquage dynamique des données

Lorsque votre application envoie une requête de données, PolarDB masque les données sensibles interrogées avant de renvoyer les résultats à l'application.

Pour ce faire, spécifiez le compte de base de données, le nom de la base de données ainsi que la table ou la colonne à masquer avant l'exécution de la requête.

  • Aucune modification des applications de votre système métier n'est requise, ce qui réduit les coûts.

  • Vos applications peuvent interroger les données en temps réel directement depuis les bases de données de production.

Par rapport aux bases de données miroirs, les performances des requêtes sur les bases de production sont légèrement inférieures, car PolarProxy masque les données sensibles en temps réel.

Masquage statique des données

PolarProxy exporte toutes les données d'une base de production vers une base de données miroir, en chiffrant ou en masquant les données sensibles lors de l'exportation.

Votre application interroge les bases de données miroirs plutôt que celles de production. Ainsi, le masquage des données n'affecte pas les services nécessitant un accès aux bases de production.

  • Le masquage des données sensibles exige le développement de composants spécifiques dans l'outil d'importation de données, ce qui engendre des coûts de développement élevés.

  • Les données présentes dans les bases miroirs ne sont pas synchronisées en temps réel avec celles des bases de production.

Fonctionnement

Une fois les règles de masquage configurées dans la console PolarDB, celle-ci les transmet à PolarProxy. Lorsque votre application se connecte à une base de données via le compte défini dans les règles de masquage et interroge les colonnes spécifiées, PolarProxy masque les données extraites avant de les renvoyer au client. 1

La figure précédente illustre les règles de masquage suivantes :

  • Ces règles ne s'appliquent que si vous utilisez le compte testAcc pour interroger la base de données.

  • PolarProxy masque uniquement les données interrogées dans les colonnes name et age.

Remarque

Si une colonne du résultat de requête est soumise au masquage, toutes ses valeurs sont masquées. Par exemple, si vous exécutez l'instruction SELECT * FROM t1 et que la table t1 contient les colonnes name et age, les valeurs de ces deux colonnes apparaissent masquées dans le résultat.

Supposons que votre application utilise le compte testAcc pour se connecter à une base de données et interroger les colonnes name, age et hobby d'une table. Dans ce cas, PolarProxy masque les données des colonnes name et age, puis renvoie ces données masquées accompagnées des données non masquées de la colonne hobby.

PolarProxy applique différentes méthodes de masquage selon le type de données. Le tableau suivant détaille ces méthodes.

Type de données

Méthode de masquage

Exemple

Types entiers : TINYINT, SMALLINT, MEDIUMINT, INT et BIGINT

PolarProxy renvoie une valeur aléatoire respectant le format du type de données d'origine.

  • Valeur d'origine : 12345

  • Valeur masquée générée aléatoirement : 28175

Types décimaux : DECIMAL, FLOAT et DOUBLE

  • Valeur d'origine : 1.2345

  • Valeur masquée générée aléatoirement : 8.2547

Types date et heure : DATE, TIME, DATETIME, TIMESTAMP et YEAR

  • Valeur d'origine : 2021-01-01 00:00:00

  • Valeur masquée générée aléatoirement : 4926-12-13 17:23:07

Autres types de données

PolarProxy remplace les données par des astérisques (*).

  • Valeur réelle : Elon Musk

  • Valeur masquée : *****

Points d'attention

  • La fonctionnalité de masquage dynamique des données s'applique exclusivement aux endpoints de cluster (endpoint par défaut et endpoints personnalisés). Si vous utilisez l'endpoint principal pour vous connecter à une base de données et exécuter des requêtes, le masquage dynamique ne s'applique pas. Pour plus d'informations sur la consultation des endpoints de cluster, reportez-vous à Afficher l'endpoint et le numéro de port.

  • Si les résultats d'une requête contiennent des données devant être masquées et que la taille d'une seule ligne dépasse 16 Mo, la session de requête est interrompue.

    Prenons l'exemple d'une requête portant sur les colonnes name et description de la table person. Dans cette table, les données sensibles de la colonne name doivent être masquées, tandis que la taille des données d'une ligne dans la colonne description excède 16 Mo. Dans ce scénario, l'exécution de l'instruction SELECT name, description FROM person entraîne la fermeture de la session de requête.

  • Le masquage ne fonctionne pas si la colonne contenant les données sensibles à masquer est utilisée comme paramètre d'entrée d'une fonction.

    Par exemple, supposons qu'une règle ait été créée pour masquer les données sensibles de la colonne name. Lors de l'exécution de l'instruction SELECT CONCAT(name, '') FROM person, votre application peut toujours lire les valeurs brutes de la colonne name.

  • L'utilisation de l'opérateur UNION sur une colonne ciblée par le masquage peut empêcher celui-ci de s'appliquer correctement.

    À titre d'illustration, si une règle vise à masquer les données sensibles de la colonne name, l'exécution de l'instruction SELECT hobby FROM person UNION SELECT name FROM person permet à votre application de continuer à lire les valeurs brutes de la colonne name.

Activer la fonctionnalité de masquage dynamique des données

Pour plus d'informations, consultez Gérer les règles de masquage des données.

Annexe : Impact sur les performances du cluster

La fonctionnalité de masquage dynamique des données affecte les performances des clusters dans les scénarios suivants.

Remarque

Dans cet exemple, le nombre de requêtes en lecture par seconde (QPS) des clusters sert à illustrer les écarts de performance.

Scénario

Impact sur les performances

Compte inclus dans la règle de masquage

Requête correspondant à la règle de masquage

Non

Non

Le masquage ne s'applique pas aux requêtes effectuées par votre compte. Les performances de votre cluster restent donc inchangées.

Oui

Non

PolarProxy analyse uniquement les métadonnées des colonnes dans le jeu de résultats, sans masquer les données brutes issues de la requête.

Cela induit une surcharge de performance d'environ 6 %. Une fois le masquage dynamique activé, le QPS en lecture seule diminue d'environ 6 %.

Oui

PolarProxy analyse les métadonnées des colonnes dans le jeu de résultats et masque les données brutes issues de la requête.

Dans ce cas, la surcharge dépend de la taille du jeu de résultats : plus le nombre de lignes retournées est élevé, plus l'impact sur les performances est important.

Pour un résultat ne comportant qu'une seule ligne, la surcharge avoisine les 6 %.