Cet article décrit une méthode de masquage dynamique des données (DDM) disponible pour les sites IRI FieldShield premium qui utilise un système basé sur un proxy pour intercepter les requêtes d'application vers les bases de données connectées à JDBC. Il s'agit de l'une des nombreuses approches de masquage des données en vol que les utilisateurs de FieldShield peuvent envisager.
Les autres options IRI DDM incluent :Fonctions FieldShield appelables par API intégrées dans des programmes C/C++/C#, Java ou .NET; fonctions FieldShield en temps réel intégrées dans les procédures SQL qui créent des vues masquées ; et démasquage dynamique des tableaux masqués statiquement pour les utilisateurs autorisés.
Le système basé sur un proxy présenté ici utilise un pilote « JDBC SQL Trail » spécifique à la base de données, associé à une application Web de configuration et de gestion appelée SQL Sharp (SQL#). Ce diagramme montre l'architecture du système avant et après la mise en œuvre :
Cette application prend actuellement en charge les plates-formes de bases de données relationnelles suivantes :
- Oracle 11g, 12c, 18/19c
- PostgreSQL 9.5, 9.6, 10, 11
- MS SQL 2014, 2016
- SAP HANA 2.0
et nécessite les composants tiers suivants :
- MS Windows 7, 10 ou Server 2012 et versions ultérieures (testé).
- Java JDK et JRE 1.8 ou version ultérieure
- Tomcat 8.5 ou supérieur pour exécuter le serveur Web SQL#.
- Un navigateur Web moderne, tel que :
- Google Chrome
- Mozilla Firefox
- Apple Safari
- Microsoft Edge
- Oracle ou PostgreSQL comme base de données du référentiel pour stocker :
- Configuration des utilisateurs et des groupes SQL#
- Contrôles d'accès et d'activité à la base de données
- Règles de masquage dynamique des données
- Journaux d'audit SQL
Comment ça marche ?
Dans l'application Web SQL #, vous créez des politiques de masquage des données pour masquer les valeurs de colonne en vol pour tous les utilisateurs sauf autorisés qui se connectent à la base de données via le pilote JDBC SQL Trail. Vous devez installer et configurer ce pilote pour chaque instance de base de données que vous souhaitez protéger.
Les règles DDM définissent les tables et les colonnes à masquer, ainsi que la manière dont les valeurs masquées s'afficheront. Une fois le système correctement configuré, toutes les requêtes connectées via le pilote seront soumises à la politique de masquage.
Il est également possible de définir des politiques pour empêcher les utilisateurs de se connecter et certaines activités SQL. Un journal d'audit complet de connexion et d'activité SQL est produit et consultable en SQL#.
Le pilote ne fait pas de distinction entre les utilisateurs de l'application à des fins de blocage, de masquage ou d'audit. Cependant, vous pouvez autoriser des utilisateurs spécifiquement nommés (établissant des connexions de serveur d'application alternatives à la base de données via le même pilote) à voir les données non masquées.
Création d'une politique de masquage
Pour créer une politique de masquage dans SQL#, utilisez la Politique de masquage de l'onglet SQL# Execute Management filtrer. Sélectionnez le + Icône (Ajouter) à droite de la Liste des règles de masquage étiquette.
Donnez un nom à la règle de masquage et une description facultative. Vous pouvez ensuite choisir le type de masque qui s'appliquera à partir de la Masing Regex : dans le menu déroulant Ajouter une règle de masquage boîte de dialogue.
Les trois premières options sont prédéfinies, tandis que la Regex vous permet de définir un format de masquage personnalisé. Cliquez sur le + Icône (Ajouter) à droite de TAB/COL étiquette pour ajouter une ou plusieurs combinaisons de table et de colonne, pour spécifier quelles valeurs de données seront masquées.
Une fois chaque combinaison de tableau et de colonnes créée, cliquez sur Ajouter bouton au milieu de la boîte de dialogue pour les mettre dans la liste. Lorsque vous avez terminé de spécifier les emplacements des tables et des colonnes, cliquez sur Ajouter bouton en bas pour ajouter les emplacements à Ajouter une règle de masquage boîte de dialogue.
Enfin, cliquez sur Enregistrer au bas de la Ajouter une règle de masquage boîte de dialogue lorsque vous avez terminé avec la règle de masquage. À ce stade, tous les utilisateurs configurés pour accéder aux données verront des valeurs masquées lors de la connexion via le pilote proxy JDBC SQL Trail.
Pour autoriser un utilisateur à afficher des données non masquées, vous devez l'ajouter à la Liste des utilisateurs non masqués , comme décrit ci-dessous.
Accorder l'autorisation aux utilisateurs
Au sein de la même Politique de masquage de l'onglet SQL# Execute Management filtrer. Cliquez sur le + Icône (Ajouter) à droite de la Liste des utilisateurs non masqués étiqueter. Cela affichera le Rechercher un utilisateur boîte de dialogue dans laquelle vous pouvez sélectionner un ou plusieurs utilisateurs pour lesquels les requêtes dans les colonnes et les tables sélectionnées ne seront pas masquées.
Cliquez sur Enregistrer en bas de la boîte de dialogue lorsque vous avez terminé de sélectionner les utilisateurs.
Utilisation de SQL# et SQL Trail à partir d'applications de base de données
Dans cet exemple, notre application de base de données sera IRI Workbench, l'environnement de conception de travail frontal Eclipse pour Voracity, FieldShield et d'autres produits logiciels IRI.
Pour activer vos applications pour le contrôle SQL et le masquage dynamique des données à l'aide du serveur proxy SQL# et du pilote JDBC SQL Trail, vous devrez activer SQL# via Tomcat et son serveur proxy. Vous devez également configurer le pilote JDBC SQL Trail dans la vue IRI Workbench Data Source Explorer, ainsi que les politiques DDM dans SQL# comme décrit ci-dessus.
Voici une vue de l'instance Oracle connectée via le pilote JDBC SQL Trail.
Notez que toutes les opérations normales de base de données et les assistants de travail IRI continueront à fonctionner via cette connexion. Cela signifie également que toute activité non autorisée d'IRI Workbench sera bloquée et que toutes les commandes SQL émises à partir d'ici vers la base de données connectée seront enregistrées dans le journal d'audit SQL#.
Il s'agit d'une requête Workbench sur la table ORDERS qui a été configurée pour DDM dans SQL# :
par rapport à la même requête exécutée par un utilisateur autorisé, qui affiche les données non masquées d'origine :
Pendant ce temps, dans la section de journalisation de l'application SQL#, vous pouvez voir notre enregistrement de requête :
à partir de l'adresse IP d'IRI Workbench.
