Contrôles au niveau colonne et ligne

peuvent renforcer la sécurité de la base de données en permettant de cacher aux yeux de l’utilisateur les colonnes à contenu sensible. L’exemple de la figure 6 utilise SQL pour démontrer cette technique de sécurité. Vous pouvez aussi l’appliquer en utilisant des fichiers logiques et des commandes de sécurité CL. Dans cet exemple, EMP_TAB est la table DB2 qui contient des données sur chaque employé. La première étape consiste à définir une vue SQL, EMPVIEW, qui omet la colonne Salaire (sensible par nature) de sa définition. L’accès à la table sous-jacente est ensuite retiré par l’instruction REVOKE, et les utilisateurs « normaux » ne reçoivent des autorités que sur la vue par l’instruction GRANT. De ce fait, USER1 ne peut accéder qu’à l’ID et au nom de l’employé parce que ce sont les seules colonnes définies dans la vue.

Nous créons une seconde vue pour les utilisateurs des ressources humaines (HR) qui requièrent l’accès à la colonne Salaire. A noter que même le profil utilisateur HR n’a pas les privilèges pour accéder à la table : l’accès est là encore limité à la vue, empview_hr. Au fur et à mesure que de nouvelles colonnes sont ajoutées à la table sous-jacente, les utilisateurs des vues doivent se voir accorder explicitement l’accès aux données dans les nouvelles colonnes, au lieu de donner automatiquement à tous les utilisateurs de table autorisés l’accès à la nouvelle colonne. Au lieu de cacher les colonnes sensibles, vous pourriez aussi utiliser des vues pour masquer les données dans des colonnes sensibles, comme dans l’exemple suivant :

CREATE VIEW empview_mask AS
SELECT empid, empname, -999999.99
salmask FROM emp_tab

En outre, si vous devez cantonner les utilisateurs à un sous-ensemble de lignes dans une table, vous pourriez ajouter des prédicats de sélection à la définition de vue, comme dans l’exemple suivant.

CREATE VIEW empview_hrsub AS
SELECT empid, empname, empsalary
FROM emp_tab
WHERE empsalary < 1000000

Le principal inconvénient de l’approche vue est que la création de vues supplémentaires entraîne de nouveaux objets DB2 à gérer et à administrer. Si vous n’utilisez que des vues SQL et des fichiers logiques non indexés, les performances des applications ne sont pas dégradées parce que ces objets DB2 ne contiennent aucune donnée qui doive être maintenue quand la table sous-jacente change. Si vous utilisez un fichier logique indexé à cet effet, il y aura un léger prix de performance à payer parce que DB2 doit mettre à jour le fichier logique chaque fois que la table sous-jacente change.

DB2 for i permet aussi de définir les autorités de données au niveau colonne. Mais peu de gens utilisent cette possibilité parce qu’ils ne peuvent contrôler les opérations de mise à jour qu’au niveau colonne – les opérations de lecture ne sont pas supportées au niveau colonne. La possibilité de contrôler les mises à jour au niveau colonne peut s’avérer utile quand il faut laisser des utilisateurs mettre à jour certaines des colonnes d’une table, mais pas toutes. Par exemple, dans la figure 7, le profil utilisateur HRADMIN se voit accorder l’accès pour effectuer toute opération de données sur toute colonne de la table emp_tab. En revanche, le profil HRUSER est limité à mettre à jour les colonnes empid et empname et à lire les lignes de la table. Seules les instructions SQL GRANT et REVOKE supportent la sécurité au niveau colonne.