Sécurité des entrepôts de données : analyse approfondie de la technologie de désensibilisation des données

L'équipe de la communauté open source chinoise a réalisé sa première diffusion en direct, racontant l'histoire de la communauté open source chinoise au nom du partage.

Cet article est partagé par la communauté Huawei Cloud « Introduction aux principes de désensibilisation des données et aux méthodes d'utilisation de la gestion de la sécurité GaussDB (DWS) » par VV Yixiao.

1. Introduction

Versions applicables : 8.2.0 et supérieures

La fonction de désensibilisation des données des produits GaussDB (DWS) constitue une avancée technologique importante pour les produits de bases de données afin d'internaliser et de consolider les capacités de sécurité des données. Il fournit la fonction de désensibilisation des données sensibles au niveau des colonnes dans le cadre des utilisateurs désignés. Il présente les avantages de flexibilité, d'efficacité, de transparence, de convivialité, etc. Il améliore considérablement les capacités de sécurité des données du produit et assure une protection fiable des données sensibles. .

L’arrivée de l’ère du Big Data a bouleversé le modèle opérationnel des entreprises traditionnelles et stimulé de nouveaux potentiels de production. Les données sont devenues un facteur de production important et un support d’informations, et le flux de données cache également des informations de valeur d’ordre supérieur. Pour les contrôleurs de données et les sous-traitants, la manière de maximiser la valeur du flux de données constitue l'intention initiale et l'importance de l'exploration de données. Cependant, la révélation d’une série d’incidents de fuite d’informations a amené une attention de plus en plus large à la sécurité des données. Les pays et les régions établissent et améliorent progressivement les lois et réglementations liées à la sécurité des données et à la protection de la vie privée afin de fournir une protection juridique à la protection de la vie privée des utilisateurs. Comment renforcer la sécurité des données et la protection de la vie privée au niveau technique et proposer davantage d'exigences fonctionnelles pour le produit d'entrepôt de données lui-même est également le moyen le plus efficace de renforcer la sécurité des données.

La version 8.1.1 du produit GaussDB (DWS) lance la fonction de désensibilisation des données, qui fournit la fonction de désensibilisation pour les données sensibles au niveau des colonnes dans la plage d'utilisateurs spécifiée. Elle présente les avantages de flexibilité, d'efficacité, de transparence et de convivialité, et améliore considérablement la fonctionnalité. capacités de sécurité des données du produit.

2. Le concept de désensibilisation des données

Le masquage des données, comme son nom l'indique, consiste à protéger les données sensibles. Toute donnée susceptible de causer un préjudice grave à la société ou aux individus en cas de fuite est une donnée sensible commune. Les informations personnelles identifiables, telles que le nom, le numéro d'identification, l'adresse, le numéro de téléphone portable et l'adresse e-mail, ne sont pas adaptées pour divulguer des informations telles que le numéro de licence commerciale, le certificat d'enregistrement fiscal, le salaire de l'employé, les informations sur l'appareil telles que l'adresse IP, le MAC. adresse, numéro de carte bancaire, informations protégées sur votre santé, droits de propriété intellectuelle, etc. sont autant d'informations sensibles. Ces informations sensibles sont déformées grâce à des règles de désensibilisation pour obtenir une protection fiable des données privées. Les règles de désensibilisation courantes dans l'industrie incluent le remplacement, le réarrangement, le cryptage, la troncature et le masquage. Les utilisateurs peuvent également personnaliser les règles de désensibilisation en fonction de l'algorithme de désensibilisation souhaité.

Généralement, une bonne mise en œuvre de la désensibilisation des données doit suivre les deux principes suivants : premièrement, essayer de conserver les informations significatives avant la désensibilisation pour les applications après la désensibilisation ;

La désensibilisation des données est divisée en désensibilisation des données statiques et désensibilisation des données dynamiques. La désensibilisation des données statiques est le « remplacement du mouvement et de la simulation » des données. Une fois les données extraites et désensibilisées, elles sont envoyées aux liens en aval pour un accès, une lecture et une écriture gratuits. Après la désensibilisation, les données sont isolées de l'environnement de production, ce qui satisfait. répondre aux besoins métiers tout en assurant la sécurité de la base de données de production. La désensibilisation dynamique des données effectue un traitement de désensibilisation en temps réel tout en accédant aux données sensibles. Elle peut mettre en œuvre différents schémas de désensibilisation pour différents rôles, différentes autorisations et différents types de données, garantissant ainsi que les données renvoyées sont disponibles et sécurisées.

2.1 Désensibilisation dynamique des données DWS

La fonction de désensibilisation des données de GaussDB (DWS) abandonne les problèmes de dépendance élevée et de coût élevé de la désensibilisation au niveau de la couche d'application métier, et internalise la désensibilisation des données dans les capacités de sécurité du produit de base de données lui-même, offrant ainsi une solution complète, sûre, flexible et transparente. ensemble de , une solution conviviale de désensibilisation des données, qui appartient à la désensibilisation dynamique des données. Une fois que l'utilisateur a identifié les champs sensibles, il peut créer une politique de masquage en liant la fonction de masquage intégrée basée sur le champ cible. La stratégie de rédaction a une relation plusieurs-à-un avec l'objet table. Une stratégie de masquage contient trois éléments clés : un objet de table, une condition effective, une paire de fonctions masquées de colonne masquée. Il s'agit d'un ensemble de toutes les colonnes masquées de l'objet de table qui peuvent utiliser différentes fonctions de masquage en fonction des caractéristiques des données. des stratégies peuvent également être définies sur le même tableau en fonction des conditions efficaces et des paires colonne de désensibilisation-fonction de désensibilisation. Si et seulement si la condition effective est vraie, l'instruction de requête déclenchera la désensibilisation des données sensibles. Le processus de désensibilisation est intégré au moteur SQL et est transparent et invisible pour les utilisateurs de l'environnement de production.

Outil de désensibilisation d'agent tiers par rapport au moteur de désensibilisation DWS d'entrepôt de données

L'outil proxy tiers est une station de transfert entre les utilisateurs et les clusters d'entrepôts de données. Il s'agit d'un outil de désensibilisation plug-in extérieur à la base. Il ne peut pas participer directement à l'environnement de génération et les scénarios complexes sont difficiles à gérer.

DWS est un moteur de désensibilisation basé sur l'interaction directe entre la base de l'entrepôt de données et le moteur de stockage et le moteur SQL. Il effectue une désensibilisation en temps réel pendant le processus d'exécution de la requête, et les résultats de la désensibilisation sont directement renvoyés à l'utilisateur.

L'outil de désensibilisation de l'agent est une désensibilisation statique et le moteur de désensibilisation DWS est une désensibilisation dynamique.

Avantages du moteur de désensibilisation dynamique DWS

Bonne synergie de bases. Le moteur de désensibilisation parcourt de nombreux aspects de la base de l'entrepôt de données et participe à l'analyse, à la réécriture, à l'optimisation et à l'exécution du moteur SQL sur la base de stratégies de désensibilisation prédéfinies. Le processus de désensibilisation est invisible pour l'utilisateur.

Les politiques sont configurables. Les clients peuvent identifier les données sensibles en fonction de leurs propres scénarios commerciaux et de stratégies de désensibilisation prédéfinies de manière flexible pour les colonnes désignées des tableaux commerciaux.

Les stratégies sont évolutives. Le produit dispose d'une fonction de désensibilisation intégrée qui peut couvrir les effets de désensibilisation les plus courants et prend en charge les fonctions de désensibilisation définies par l'utilisateur.

Disponibilité des données. Les données sensibles d'origine de la base de données participent à l'opération, et ne sont désensibilisées qu'au moment de quitter la base de données (au moment du retour des résultats).

L'accès aux données est contrôlé. Les données sensibles originales ne seront pas visibles par les utilisateurs dans les conditions d'entrée en vigueur de la politique de désensibilisation.
Toutes les données de la scène ne seront pas divulguées. L'interaction de base peut réduire le risque potentiel de fuite des liaisons de transmission de données sensibles,

Il est plus sécurisé et fiable, identifie pleinement divers scénarios potentiels de phishing malveillant et offre une protection efficace.

3. Comment utiliser la désensibilisation des données

La désensibilisation dynamique des données est un processus de désensibilisation en temps réel basé sur le fait que les conditions efficaces soient remplies lors de l'exécution de l'instruction de requête. Les conditions de validation sont généralement basées sur le jugement du rôle d'utilisateur actuel. La plage visible des données sensibles est prédéfinie pour différents utilisateurs. L'administrateur système a la plus haute autorité et peut voir n'importe quel champ de n'importe quelle table à tout moment. L'identification des rôles d'utilisateurs restreints est la première étape dans la création d'une stratégie de désensibilisation.

Les informations sensibles dépendent du scénario commercial réel et des dimensions de sécurité. En prenant comme exemple les personnes physiques, les champs sensibles des utilisateurs individuels comprennent : le nom, le numéro d'identification, le numéro de téléphone portable, l'adresse e-mail, etc. dans le système bancaire, en tant que client ; , cela peut également impliquer le numéro de carte bancaire, l'heure d'expiration, le mot de passe de paiement, etc. dans le système de l'entreprise, en tant qu'employé, cela peut également impliquer le salaire, la formation, etc. impliquent également des informations sur le traitement médical, etc. Par conséquent, identifier et trier les domaines sensibles dans des scénarios commerciaux spécifiques constitue la deuxième étape de la création d’une stratégie de désensibilisation.

Le produit dispose d'une série d'interfaces de fonction de désensibilisation communes intégrées, qui peuvent spécifier des paramètres pour différents types de données et caractéristiques de données afin d'obtenir différents effets de désensibilisation. La fonction de désensibilisation peut utiliser les trois interfaces intégrées suivantes et prend également en charge les fonctions de désensibilisation personnalisées. Les trois fonctions de désensibilisation intégrées peuvent couvrir les effets de désensibilisation dans la plupart des scénarios. Il n'est pas recommandé d'utiliser des fonctions de désensibilisation personnalisées.

MASK_NONE : pas de désensibilisation, uniquement pour les tests internes.
MASK_FULL : Désensibilisation complète à une valeur fixe.
MASK_PARTIAL : utilisez les caractères de masquage spécifiés pour masquer partiellement le contenu dans la plage de masquage.

Différentes colonnes de désensibilisation peuvent utiliser différentes fonctions de désensibilisation. Par exemple, les numéros de téléphone portable affichent généralement les quatre derniers chiffres et remplacent les premiers chiffres par « * » ; le montant est affiché uniformément sous la forme d'une valeur fixe de 0, etc. La détermination de la fonction de désensibilisation qui doit être liée à la colonne de désensibilisation est la troisième étape de la création d'une stratégie de désensibilisation.

En prenant comme exemple la table des employés emp d'une entreprise, l'utilisateur propriétaire de la table Alice et les utilisateurs matu et juillet, nous présenterons brièvement le processus d'utilisation de la désensibilisation des données. Parmi eux, la table emp contient les noms des employés, les numéros de téléphone portable, les e-mails, les numéros de carte de paiement, les salaires et d'autres données privées. L'utilisateur Alice est la responsable des ressources humaines, et les utilisateurs Matu et July sont des employés ordinaires.

On suppose que la table, l'utilisateur et les autorisations d'affichage de l'utilisateur sur la table emp sont tous en place.

1. Créez une politique de désensibilisation mask_emp, qui permet uniquement à Alice de visualiser toutes les informations sur les employés. Matu et July ne sont pas visibles sur les numéros de carte de paie et les salaires. Le champ card_no est un type numérique, et MASK_FULL est utilisé pour le désensibiliser complètement à une valeur fixe de 0 ; le champ card_string est un type de caractère, et MASK_PARTIAL est utilisé pour désensibiliser partiellement les données d'origine selon le format d'entrée et de sortie spécifié ; le champ salaire est de type numérique, et le chiffre 9 est utilisé pour le désensibiliser partiellement. Toutes les valeurs numériques avant l'avant-dernier chiffre.

postgres=# CRÉER UNE POLITIQUE DE REDACTION mask_emp ON emp WHEN (current_user != 'alice')

AJOUTER UNE COLONNE card_no AVEC mask_full(card_no),

AJOUTER UNE COLONNE card_string AVEC mask_partial(card_string, 'VVVVFVVVVFVVVVFVVVV','VVVV-VVVV-VVVV-VVVV','#',1,12),

AJOUTER UNE COLONNE salaire AVEC masque_partial(salaire, '9', 1, longueur(salaire) - 2);

Passez à matu et juillet et consultez la table des employés emp.

postgres=> FIXER LE RÔLE matu MOT DE PASSE 'Gauss@123';

postgres=> SELECT * FROM emp;

 identifiant | nom | numéro de téléphone | numéro de carte | chaîne_carte | courrier électronique | salaire | anniversaire       

----+------+-------------+---------+-------------- -------+------------+------------+------ ---------------

  1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00

  2 | bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00

  3 | ici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3 lignes)

postgres=> FIXER LE RÔLE juillet MOT DE PASSE 'Gauss@123';

postgres=> SELECT * FROM emp;

 identifiant | nom | numéro de téléphone | numéro de carte | chaîne_carte | courrier électronique | salaire | anniversaire       

----+------+-------------+---------+-------------- -------+------------+------------+------ ---------------

  1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00

  2 | bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00

  3 | ici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3 lignes)

2. En raison de l'adaptation du travail, Matu est entrée au Département des ressources humaines pour participer aux questions de recrutement de l'entreprise, et toutes les informations sur les employés étaient également visibles, modifiant ainsi les conditions d'application de la politique.

postgres=> ALTER REDACTION POLICY mask_emp ON emp WHEN(current_user NOT IN ('alice', 'matu'));

Basculez vers les utilisateurs matu et juillet et affichez à nouveau la table des employés emp.

postgres=> FIXER LE RÔLE matu MOT DE PASSE 'Gauss@123';

postgres=> SELECT * FROM emp;

 identifiant | nom | numéro de téléphone | numéro de carte | chaîne_carte | courrier électronique | salaire | anniversaire       

----+------+-------------+--------+----- ----------------+------------+--------------- ---+-----------------------------------

  1 | anny | 13420002340 | 1234123412341234 | 1234-1234-1234-1234 | [email protected] | 10000.0000 | 1999-10-02 00:00:00

  2 | bob | 18299023211 | 3456345634563456 | 3456-3456-3456-3456 | [email protected] | 9999.9900 | 1989-12-12 00:00:00

  3 | ici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3 lignes)

postgres=> FIXER LE RÔLE juillet MOT DE PASSE 'Gauss@123';

postgres=> SELECT * FROM emp;

 identifiant | nom | numéro de téléphone | numéro de carte | chaîne_carte | courrier électronique | salaire | anniversaire       

----+------+-------------+---------+-------------- -------+------------+------------+------ ---------------

  1 | anny | 13420002340 | 0 | ####-####-####-1234 | [email protected] | 99999.9990 | 1999-10-02 00:00:00

  2 | bob | 18299023211 | 0 | ####-####-####-3456 | [email protected] | 9999.9990 | 1989-12-12 00:00:00

  3 | ici | 15512231233 | | | [email protected] | | 1992-11-06 00:00:00

(3 lignes)

3. Les informations sur l'employé, numéro de téléphone, e-mail et anniversaire, sont également des données privées. Mettez à jour la politique de masquage mask_emp et ajoutez trois colonnes de masquage.

postgres=> MODIFIER LA POLITIQUE DE REDACTION mask_emp ON emp AJOUTER UNE COLONNE phone_no AVEC mask_partial(phone_no, '*', 4);

postgres=> MODIFIER LA POLITIQUE DE REDACTION mask_emp ON emp AJOUTER UNE COLONNE email AVEC mask_partial(email, '*', 1, position('@' dans l'e-mail));

postgres=> MODIFIER LA POLITIQUE DE REDACTION mask_emp ON emp AJOUTER UNE COLONNE anniversaire AVEC mask_full(birthday);

Passez à l'utilisateur juillet et affichez la table des employés emp.

postgres=> FIXER LE RÔLE juillet MOT DE PASSE 'Gauss@123';

postgres=> SELECT * FROM emp;

 identifiant | nom | numéro de téléphone | numéro de carte | chaîne_carte | courrier électronique | salaire | anniversaire       

----+------+-------------+---------+-------------- -------+------------+------------+------ ---------------

  1 | anny | 134********* | 0 | ####-####-####-1234 | ********163.com | 99999.9990 | 1970-01-01 00:00:00

  2 | bob | 182********* | 0 | ####-####-####-3456 | ***********qq.com | 9999.9990 | 1970-01-01 00:00:00

  3| ici | 155********* | | | **************sina.com | | 1970-01-01 00:00:00

(3 lignes)

4. Compte tenu de la convivialité de l'interaction avec l'utilisateur, GaussDB (DWS) fournit des vues système redaction_policies et redaction_columns pour permettre aux utilisateurs de visualiser directement davantage d'informations de désensibilisation.

postgres=> SELECT * FROM redaction_policies;

 schéma_objet | propriétaire_objet | nom_objet | nom_politique | expressions | activer | politique_description

---------------+--------------+-------------+----- ----+-------------------------+---------- ---+--------------------

 publique | Alice | emp | masque_emp | ("current_user"() = 'juillet'::name) | t |

(1 rangée)

postgres => SELECT nom_objet, nom_colonne, info_fonction FROM redaction_columns ;

 nom_objet | nom_colonne | fonction_info                                             

-------------+-------------+---------------------- -------------------------------------------------- -------------------------------

 emp | numéro de carte | masque_full(carte_no)

 emp | chaîne_carte | masque_partial(card_string, 'VVVVFVVVVFVVVVFVVVV'::text, 'VVVV-VVVV-VVVV-VVVV'::text, '#'::text, 1, 12)

 emp | courrier électronique | mask_partial(email, '*'::text, 1, "position"(email, '@'::text))

 emp | salaire | mask_partial(salaire, '9'::text, 1, (length((salary)::text) - 2))

 emp | anniversaire | mask_full (anniversaire)

 emp | numéro de téléphone | masque_partial(numéro_téléphone, '*'::texte, 4)

(6 lignes)

5. Du coup, un jour, lorsque les informations sur les employés pourront être partagées au sein de l'entreprise, il suffit de supprimer la politique de masquage mask_emp de la table emp.

postgres=> DROP REDACTION POLICY mask_emp ON emp;

Pour plus de détails sur l'utilisation, veuillez vous référer à la documentation du produit GaussDB (DWS).

4. Désensibilisation invisible des données

Lors de l'utilisation de la fonction de désensibilisation des données, il peut arriver que des données sensibles soient traitées et calculées avant leur sortie. Dans ce cas, si les données désensibilisées sont utilisées pour des calculs dans la base de données, les données désensibilisées elles-mêmes auront un impact sur les résultats de la requête dans des conditions telles que les fonctions d'agrégation et les conditions de filtrage. Par conséquent, les données désensibilisées seront utilisées pour résoudre ce phénomène. . Min introduit la possibilité de compter comme invisible. Ce qu'on appelle invisible signifie que les données sensibles d'origine sont utilisées dans la base de données pour participer aux calculs de traitement, et que les données sensibles ne sont désensibilisées que lorsqu'elles sont expédiées hors de la base de données. Pour utiliser la fonction invisible calculable, vous devez définir le commutateur activate_redactcol_computable=on.

Actuellement, les scénarios qui prennent en charge la participation directe de données sensibles aux calculs de traitement sont les suivants :

SELECT nullif(salary, 1) FROM emp expression de colonne de projection nullif;
SELECT email LIKE '%.com' FROM emp colonne projetée LIKE expression;
SELECT to_days(birth) FROM david.emp ; fonction de colonne de projection to_days
SELECT count(*) FROM emp; fonction d'agrégation
SELECT * FROM emp OÙ le cardid N'EST PAS NULL ; conditions de filtre ;
SELECT nom, avg(salary) * 12 FROM emp GROUP BY nom ; condition de regroupement (le nom est un champ désensibilisé)
SELECT (SELECT salaire+10 FROM emp ORDER BY id LIMIT 1) ; expression de colonne de projection de position de sous-requête ;
Les deux tables utilisent des champs sensibles comme conditions d'association
Colonne projetée d'expression CTE

Les scénarios qui déclenchent la désensibilisation des données au moment de l'expédition sont les suivants :

Requête de table
Afficher la requête
Clause RETOUR DML
COPIERExporter
Exportation de table GDS
CURSEUR… RÉCUPÉRER
La définition de procédure stockée utilise la table masquée pour interroger la procédure stockée.

4.1 Héritage de la stratégie de désensibilisation

Pour les instructions INSERT/UPDATE/MERGE INTO/CREATE TABLE AS, lorsque la sous-requête est une opération de projection sur un champ sensible, l'héritage désensibilisé sera déclenché, afin que la nouvelle table contenant les informations sensibles contienne les mêmes informations que la table source. La stratégie évite le problème de fuite de données sensibles en insérant les données sensibles de la table source dans une nouvelle table, puis en interrogeant la nouvelle table. De plus, l'héritage de la politique de masquage appartient à l'activité de dimension de table, et l'activité d'héritage ne fait pas attention à savoir si la politique de masquage prend effet dans la session actuelle ou dans les conditions de rôle dans la partie sous-requête.

La première étape pour hériter de la stratégie de désensibilisation consiste à effectuer une analyse de lignée sensible pour que tout utilisateur exécute une instruction DML, la partie sous-requête de la table source et sa colonne de projection cible seront parcourues une fois que la stratégie de désensibilisation existe dans la table source et. la colonne de projection cible est un champ de désensibilisation. On considère que lors de l'utilisation de la table source pour insérer/mettre à jour les données de la table cible, il existe un risque d'exposer les données sensibles de la table source.

Lors de l'héritage d'une stratégie de masquage, générez d'abord les informations de stratégie de masquage et les informations de champ de masquage qui s'appliquent à la table cible à partir des informations sensibles de la table source marquée dans le parcours. Ensuite, le système intégré génère une déclaration de création de politique et l'écrit dans la table système pg_redaction_policy/pg_redaction_column. La politique de désensibilisation intégrée est nommée "inherited_rp". Enfin, définissez le champ de marque d’héritage des métadonnées de la table système sur true.

Notez que si la session/l'utilisateur d'exécution INSERT remplit les conditions de déclenchement, lorsque le résultat de l'insertion est imprimé avec la clause RETURNING, le résultat renvoyé sera désensibilisé et les informations du journal « Politiques/colonnes de rédaction parentales » enregistreront la source de l'héritage de la politique. .

Avec l’introduction du comportement d’héritage des politiques de désensibilisation, certains scénarios de conflits entre politiques de désensibilisation sont apparus. Par exemple, la colonne cible de la requête de l'instruction SELECT n'est pas le champ sensible d'origine, mais une expression complexe du champ sensible. L'expression est d'abord calculée puis désensibilisée. Comment définir le comportement de désensibilisation dans ce cas ? Les deux sous-branches de l'opération d'ensemble SETOP utilisent des effets de désensibilisation différents pour la même colonne cible. Comment définir le résultat de désensibilisation de la colonne cible de l'instruction externe à ce moment-là ? Dans l'analyse de lignage sensible de plusieurs opérations INSERT/UPDATE, les colonnes de projection de la table source de la même colonne cible adoptent des effets de désensibilisation différents, et les conditions effectives de la politique de la table source peuvent également être différentes. Comment la politique de désensibilisation doit-elle être héritée dans ce cas. ?

Pour ces scénarios de conflit, basés sur le principe selon lequel la protection des données sensibles de l'utilisateur contre la fuite prime sur l'effet de désensibilisation des données sensibles qui n'ont pas de caractéristiques d'origine, lorsqu'un conflit d'effet de désensibilisation est rencontré, il est mis à niveau vers l'effet de désensibilisation général. effet de désensibilisation mask_full. mask_full est une fonction de masquage complète qui peut couvrir n'importe quel type de données. Elle se concentre uniquement sur le type de valeur de retour d'expression, ce qui peut garantir que les données masquées ne seront pas divulguées. Cependant, le résultat masqué ne pourra pas représenter les caractéristiques de l'expression. données originales, ce qui rend le résultat masqué moins lisible. De plus, pour les expressions de fonction telles que la longueur et le nombre, les résultats du calcul n'exposeront aucune caractéristique ni information de données d'origine, donc la syntaxe ALTER FUNCTION ... [NOT] MASKED est fournie pour aider les utilisateurs à configurer manuellement une fonction non désensibilisante. liste blanche.

4.2 Protection contre le phishing malveillant

Certaines informations sensibles sont connues et, grâce à de multiples correspondances heuristiques, les informations utilisateur visibles sont corroborées à l'envers, volant ainsi les données privées de l'utilisateur. Faites correspondre de manière heuristique les informations sensibles à l'aide de conditions de filtrage ou d'opérations de projection qui facilitent les expressions sous la forme de jugements d'équivalence. Ces comportements consistant à extraire des données privées des utilisateurs via des valeurs constantes connues et des expressions de jugement d'équivalence/équivalence similaire sont des tentatives malveillantes.

postgres=> SELECT nom FROM emp WHERE nom in('张三');

INFO : Le résultat de la colonne cible {"name"} est masqué.

 nom

------

  ouvrir*

 (1 rangée)

Comme le montre l'exemple ci-dessus, bien que les informations sur le nom de l'utilisateur aient été désensibilisées, puisque la condition de requête concerne l'utilisateur « Zhang San », même s'il est désensibilisé à « Zhang* », nous pouvons toujours facilement déterminer la désensibilisation ici. les informations sensibles sont « Zhang San », ce qui entraîne un risque de fuite des informations des utilisateurs de Zhang San.

En réponse à ce problème, nous avons adopté un modèle de « pessimisme ». Tout jugement d'équivalence constante peut comporter un risque d'arbitrage malveillant et devrait être interdit. Les exemples sont les suivants :

postgres=> SELECT nom FROM emp WHERE nom in('张三');

ERREUR : La colonne de rédaction "nom" ne peut pas être référencée dans des conditions d'équivalence avec une valeur const.

CONSEIL : Veuillez utiliser la commande EXPLAIN pour voir plus de détails.

Les scénarios dans lesquels l’arbitrage malveillant utilisant des constantes est interdit sont résumés comme suit :

1. Expressions de jugement d'équivalence constante, expressions composées et expressions équivalentes pour les champs désensibilisés

2. En supposant que le champ de nom est un champ désensibilisé et que la session en cours remplit les conditions de déclenchement de la politique, l'instruction présente les caractéristiques suivantes (sans toutefois s'y limiter), il existe un risque d'arbitrage malveillant et l'exécution est interdite :

• nom = 'Zhang San'

• nom = 'Zhang San' OU nom = '李思'

• nom en ("Zhang San", "李思")

• Nom du CAS QUAND '张三' ALORS vrai …

• CAS QUAND nom entre ('张三', '李思') ALORS …

• Package avancé dbms_output.put_line

3. Une erreur sera signalée lors de l'exécution de l'instruction : ERREUR : la colonne de rédaction « nom » ne peut pas être référencée dans des conditions d'équivalence avec une valeur const.

5. Principe de mise en œuvre de la désensibilisation des données

La fonction de désensibilisation des données GaussDB (DWS) est basée sur le cadre d'implémentation existant du moteur SQL et permet un traitement de désensibilisation en temps réel qui est imperceptible pour le monde extérieur lors de l'exécution d'instructions de requête par des utilisateurs restreints. Concernant sa mise en œuvre interne, elle est illustrée dans la figure ci-dessus. Nous considérons la politique de rédaction comme une règle liée à l'objet table. Lors de la phase de réécriture de requête de l'optimiseur, chaque TargetEntry de la TargetList dans l'arbre de requête est parcourue si une colonne de rédaction de la table de base est impliquée, ainsi que le When actuel. Lorsque la règle de désensibilisation prend effet (c'est-à-dire que les conditions effectives de la politique de désensibilisation sont remplies et que l'activation est activée), il est conclu que l'objet Var à désensibiliser est impliqué dans cette TargetEntry. À ce moment, la table système de la colonne de désensibilisation. pg_redaction_column est parcouru pour trouver la liaison de colonne de désensibilisation correspondante. Une certaine fonction de désensibilisation peut être remplacée par la FuncExpr correspondante. Après la réécriture ci-dessus de l'arbre de requête, l'optimiseur générera automatiquement un nouveau plan d'exécution, l'exécuteur exécutera selon le nouveau plan et les résultats de la requête seront désensibilisés aux données sensibles.

Par rapport à l'instruction d'origine, l'exécution d'une instruction avec désensibilisation des données ajoute un traitement logique de la désensibilisation des données, ce qui entraînera inévitablement une surcharge supplémentaire pour la requête. Ce coût est principalement affecté par trois facteurs : la taille des données de la table, le nombre de colonnes masquées impliquées dans l'interrogation de la colonne cible et la fonction de masquage utilisée dans la colonne masquée.

Pour une instruction de requête simple, prenez la table tpch customer comme exemple pour tester les facteurs ci-dessus, comme le montre la figure suivante.

Dans les figures (a) et (b), le client de la table de base utilise soit la fonction de désensibilisation MASK_FULL, soit la fonction de désensibilisation MASK_PARTIAL en fonction du type de champ et des caractéristiques. MASK_FULL désensibilise uniquement les données originales de n'importe quelle longueur et type à une valeur fixe, de sorte que le résultat de sortie est très différent des données originales. La figure (a) montre le temps d'exécution d'instructions de requête simples dans des scénarios désensibilisés et non désensibilisés selon différentes échelles de données. Les icônes pleines représentent des scénarios de non-désensibilisation et les icônes creuses représentent des utilisateurs restreints, c'est-à-dire des scénarios de désensibilisation. On peut voir que plus la taille des données est grande, plus la différence entre le temps de requête avec désensibilisation et la déclaration d'origine est grande. La figure (b) montre l'impact de différents nombres de colonnes masquées impliquées dans la requête sur les performances d'exécution des instructions sous une échelle de données 10x. Lorsqu'une colonne masquée est impliquée, la requête avec masquage est plus lente que l'instruction d'origine. Il ressort que cette colonne utilise la fonction de masquage partiel MASK_PARTIAL. Le résultat de la requête modifie uniquement le format du résultat et la longueur du contenu du résultat. ne change pas. Cela est conforme à la conjecture théorique selon laquelle « l'exécution d'une instruction avec désensibilisation entraînera une dégradation des performances correspondante ». À mesure que le nombre de colonnes masquées impliquées dans la requête augmentait, nous avons découvert un phénomène étrange : le scénario désensibilisé s'exécutait en réalité plus rapidement que l'instruction d'origine. En traçant plus en détail les fonctions de masquage associées aux colonnes masquées dans les scénarios multi-colonnes, nous avons constaté que c'est précisément grâce aux colonnes masquées utilisant la fonction de masquage MASK_FULL que l'ensemble de résultats de sortie permet de gagner beaucoup de temps par rapport aux données d'origine, rendant ainsi multi Les requêtes en colonnes sont plus efficaces. Les requêtes simples avec masquage des données sont en réalité beaucoup plus rapides.

Afin de prendre en charge la spéculation ci-dessus, nous avons ajusté la fonction de masquage.Toutes les colonnes masquées utilisent MASK_PARTIAL pour masquer partiellement les données d'origine, afin que la lisibilité externe des données d'origine puisse être conservée dans les résultats du masquage. Ainsi, comme le montre la figure ©, lorsque les colonnes masquées sont toutes associées à des fonctions de masquage partiel, l'instruction avec masquage des données est environ 10 % moins bonne que l'instruction originale. Théoriquement, cette dégradation se situe dans la fourchette acceptable. Le test ci-dessus concerne uniquement les instructions de requête simples. Lorsque l'instruction est suffisamment complexe pour inclure des fonctions d'agrégation ou des opérations d'expression complexes, cette dégradation des performances peut être plus évidente.

6. Résumé

Un ensemble de syntaxes simples et faciles à utiliser pour les stratégies de désensibilisation des données ;

Une série de fonctions de désensibilisation intégrées configurées de manière flexible qui couvrent les effets courants de désensibilisation des données privées ;

Une solution d'application de stratégie de désensibilisation complète et pratique permet une désensibilisation en temps réel, transparente et efficace des déclarations originales pendant l'exécution.

Dans l'ensemble, cette fonction de désensibilisation des données peut répondre pleinement aux exigences de désensibilisation des données des scénarios commerciaux des clients, prendre en charge l'effet de désensibilisation des données privées communes et assurer une protection fiable des données sensibles.

[Rappel chaleureux] Si vous avez des questions pendant l'utilisation, n'hésitez pas à communiquer et à donner votre avis à tout moment.

Cliquez pour suivre et découvrir les nouvelles technologies de Huawei Cloud dès que possible~