Introduction à Oracle Data Redaction

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Introduction à Oracle Data Redaction

Cet article a pour but de présenter, via un cas de test, l’utilisateur de Oracle Data Redaction, fonctionnalité présente depuis la version 11.2.0.4 et qui fait partie des fonctionnalités de l’option Advanced Security.

L’idée derrière cette fonctionnalité est de permettre la réécriture à la volée de certaines données critiques avant leur affichage, dans une perspective de confidentialité accrue. Cet article va s’intéresser à un cas concret,
la mise en place de restrictions sur l’affichage des numéros de cartes bancaires dans une table.

Préparation du cas de test

En tant que SYS, création d’un utilisateur de test :

Il faut à minima donner à l’utilisateur le droit d’exécution sur sys.dbms_redact pour qu’il puisse créer/modifier/supprimer des policies de rédaction :

Création de la table CLIENT pouvant stocker les numéros de cartes des clients dans un champ VARCHAR2 sous la forme « XXXX XXXX XXXX XXXX » :

Alimentation de la table avec un jeu de données :

Mise en place de policies DBMS_REDACT

A ce stade, sans surprise, le champs NUM_CB est visible dans la table lorsqu’on la requête :

Admettons désormais que l’on souhaite que le champ soit masqué lors d’un SELECT sur la table. Pour ce faire, il faut mettre en place une politique DBMS_REDACT qui s’appuie sur la fonction DBMS_REDACT.full, comme suit :

Si l’on requête à nouveau la table, on s’aperçoit que le champs NUM_CB ne s’affiche plus, il est masqué par la nouvelle policy :

Il est possible d’afficher les policies actuellement en place :

Ici, il s’agit d’une politique DBMS_REDACT.full, qui cache le champ dans son intégralité. Il est également possible de définir une policy de type DBMS_REDACT.partial qui peut cacher seulement une partie du champ.

Imaginons maintenant que l’on souhaite masquer seulement les 3 premiers groupes de digits du numéro de carte en les remplaçant par des astérisques et avec un affichage du numéro de carte au format « ****-****-****-XXXX »

Plutôt que supprimer/recréer la policy, il est également possible de la modifier. Aussi, on aurait pu arriver au même résultat avec :

Noter le paramètre supplémentaire action => DBMS_REDACT.MODIFY_COLUMN qui est nécessaire dans le cas d’une modification de policy. Le paramètre function_parameters, lui, permet de définir les règles de réécriture :

  • VVVVFVVVVFVVVVFVVVV : Format d’entrée. Les « V » représente des caractères de valeur, soit les digits de notre code de carte. Les « F » des caractères de formatage, soit ici les espaces entre chaque bloc de 4 caractères.
  • VVVV-VVVV-VVVV-VVVV : Format de sortie. Les « V » représente des caractères de valeur. Entre chaque bloc de 4 caractères, on utilise ici des tirets (-)
  • * : Caractère de remplacement pour les caractères masqués
  • 1 : Caractère de début du masquage
  • 12 : Nombre de caractères masqués à partir du caractère de début

Une requête sur la table retourne le champ NUM_CB au format demandé :

On peut également imaginer avoir besoin de masquer les numéros de carte uniquement lors de l’accès depuis un autre utilisateur Oracle. On peut spécifier via le paramètre « expression » une condition d’application de la règle. Si l’on veut que seul le user EASYTEST puisse lire les numéro de carte, il convient de modifier la policy comme suit :

Seul EASYTEST et les utilisateurs disposant du privilège EXEMPT REDACTION POLICY (typiquement, SYS) peuvent afficher les numéros de carte avec cette policy en place :

— > EASYTEST est l’exception dans la clause « expression » : le champ n’est pas réécrit

— > SYS dispose du privilège EXEMPT REDACTION POLICY : le champ n’est pas réécrit

— > Bien que disposant du droit de lecture sur la table, le champ NUM_CB est réecrit pour l’utilisateur EASYTEST2.

Cette policy améliore la sécurité de la table en ne permettant pas l’affichage des numéros de carte malgré le privilège SELECT sur la table, et ce, à l’exception du proprietaire de la table. Le cas de test est basique, mais la fonctionnalité est très souple et permet une gestion très fine des politiques de sécurité.
Voir la documentation de Oracle Data Redaction pour appréhender les sujets plus complexes.

Nettoyage du cas de test

En tant que SYS :

LinkedIn 0
Twitter
Facebook 0
Google+ 0

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *